Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- documentazione_3di_riservata:docway4:migrazione_tomcat7 [2015/03/25 12:14] – [Migrazione da Tomcat 6 a Tomcat 7] aalberghini
+++ documentazione_3di_riservata:docway4:migrazione_tomcat7 [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1
@@ Linea 1: / Linea 1: @@
-====== Migrazione da Tomcat 6 a Tomcat 7 ======
-Negli ambienti nei quali è già installato Tomcat 6 per ospitare applicativi 3DI e dovesse rendersi necessario l'aggiornamento a Tomcat 7 per installare DocWay4, è necessario adottare alcuni accorgimenti per mantenere la funzionalità degli applicativi all'interno del nuovo Tomcat.
-Oltre agli aspetti a livello di sviluppo (nuove features ecc.) che questo aggiornamento comporta, a livello sistemistico sono variati alcuni aspetti che bisogna gestire:
-  - viene ora eseguita una scansione del classpath per ogni singola applicazione in cerca di particolari annotazioni (come richiesto dalla specifica Servlet 3.0);
-  - i ruoli di gestione sono stati rinominati per differenziarli meglio;
-  - le opzioni di configurazioni che accettano regex ora richiedono che queste siano specificate come singola regola, e non come insieme di regole separate da ','.
-  - lo UserDatabaseRealm è stato innestato in un LockOutRealm, per prevenire attacchi brute-force sulle password.
-Nel seguito si esamineranno le conseguenze dei cambiamenti appena elencati.
-===== Scansione preliminare del classpath =====
-Si è osservato che questo meccanismo, oltre a produrre un rallentamento nell'avvio (piuttosto trascurabile nella maggior parte dei casi), comporta anche il mancato avvio di alcune applicazioni che contengono, all'interno del loro classpath, implementazioni diverse delle stesse specifiche quali, ad esempio, JCE (Java Cryptography Extension).
-Uno dei casi più ricorrenti è quello dei 3diws, che contengono nel loro classpath le librerie di Bouncy Castle (bc*.jar) e Cryptix (cryptix*.jar). Questo causa un loop infinito nello scanner utilizzato da Tomcat 7 per cercare le annotazioni di cui sopra, arrivando a bloccare l'avvio dell'applicazione.
-Per rimediare al problema si può procedere in due modi:
-  - mettere in un'apposita blacklist i jar fonte di problemi;
-  - annotare il descrittore dell'applicazione colpita (il web.xml) con apposite istruzioni per disabilitare la scansione del classpath.
-Nonostante la prima soluzione sia quella meno efficiente (la scansione viene effettuata comunque a tappeto ma non sui jar specificati) e più invasiva (è necessario modificare un file di configurazione di Tomcat), attualmente è quella che applichiamo, dato che la seconda non è stata ancora testata (e integrata nel codice) a sufficienza.
-==== Blacklist dei jar problematici ====
-Aprire il file <file>conf/catalina.properties</file> ed individuare la property org.apache.catalina.startup.ContextConfig.jarsToSkip. Impostarla ai seguenti valori:
-<code>
-org.apache.catalina.startup.ContextConfig.jarsToSkip=bcprov*.jar,jce*.jar,*jaxen*.jar,cryptix*.jar
-</code>
-In questo modo si evita che lo scanner apra i jar specificati per esaminarne le classi.
-==== Annotazione del descrittore dell'applicazione ====
-Come riportato anche nella [[https://tomcat.apache.org/migration-7.html#Migrating_from_6.0.x_to_7.0.x | guida ufficiale per la migrazione da Tomcat 6 a 7]], è possibile aggirare il problema modificando lievemente il descrittore dell'applicazione WEB-INF/web.xml:
-  - dichiarando di utilizzare la specifica Servlet 3.0;
-  - aggiungendo l'attributo <code>metadata-complete="true"</code> all'elemento radice <webapp>;
-  - aggiungendo un elemento <absolute-ordering/> vuoto.
-Un possibile problema di questa soluzione è l'adozione della nuova specifica Servlet 3.0 che rende quindi l'applicazione incompatibile con versioni di Tomcat più vecchie.
-===== Rinominazione dei ruoli di gestione =====
-Col passaggio a Tomcat 7, il ruolo **manager** [[https://tomcat.apache.org/migration-7.html#Manager_application | è stato rimpiazzato da diversi sotto-ruoli]]. Per poter gestire le applicazioni tramite l'interfaccia web del manager come prima, è sufficiente sostituire tutte le occorrenze del ruolo **manager** in **manager-gui** all'interno del file <file>conf/tomcat-users.xml</file>
-===== Regex one-liner =====
-Questa modifica impatta soprattutto le applicazioni che dichiarano una Valve all'interno del loro file di contesto per restringere le connessioni in ingresso a quelle provenienti solo da localhost (o, comunque, una lista ristretta di host). I file di contesto delle nostre applicazioni colpite da questo problema possono tipicamente essere i file:
-  * xway.xml
-  * DocWay4-service.xml((solo in installazioni vecchie su Tomcat 6 del periodo pre-RE, che ormai stanno scomparendo))
-Sostituire la dichiarazione della Valve da
-<code><Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1,localhost"/></code>
-a
-<code><Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/></code>
-====== Riferimenti esterni ======
-[[https://tomcat.apache.org/migration-7.html#Migrating_from_6.0.x_to_7.0.x | Guida ufficiale per la migrazione da Tomcat 6 a 7]]