Differenze

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

--- documentazione_3di_riservata:docway4:migrazione_tomcat7 [2015/03/25 11:43] – 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 due 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 ','.
-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 =====
-====== 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.]]