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:

1. viene ora eseguita una scansione del classpath per ogni singola applicazione in cerca di particolari annotazioni (come richiesto dalla specifica Servlet 3.0);
2. i ruoli di gestione sono stati rinominati per differenziarli meglio;
3. 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.

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:

1. mettere in un'apposita blacklist i jar fonte di problemi;
2. 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.

Aprire il file

conf/catalina.properties

ed individuare la property org.apache.catalina.startup.ContextConfig.jarsToSkip. Impostarla ai seguenti valori:

org.apache.catalina.startup.ContextConfig.jarsToSkip=bcprov*.jar,jce*.jar,*jaxen*.jar,cryptix*.jar

In questo modo si evita che lo scanner apra i jar specificati per esaminarne le classi.

Come riportato anche nella guida ufficiale per la migrazione da Tomcat 6 a 7, è possibile aggirare il problema modificando lievemente il descrittore dell'applicazione WEB-INF/web.xml:

1. dichiarando di utilizzare la specifica Servlet 3.0;
2. aggiungendo l'attributo

   metadata-complete="true"

   all'elemento radice <webapp>;

3. 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.

Col passaggio a Tomcat 7, il ruolo manager è 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

conf/tomcat-users.xml

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¹⁾

Sostituire la dichiarazione della Valve da

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1,localhost"/>

a

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/>

Guida ufficiale per la migrazione da Tomcat 6 a 7