Tomcat gestione del contesto

Question

Il 6.0 documento gatto a http://tomcat.apache.org/tomcat-6.0-doc/config/context.html dice:

Solo se un file di contesto non esiste per l'applicazione nel $CATALINA_BASE/conf/[enginename]/[hostname]/, in un singolo file a /META-INF/context.xml all'interno dei file di applicazione. Se l'applicazione Web è impacchettata come WAR, allora /META-INF/context.xml verrà copiata in $CATALINA_BASE/conf/[enginename]/[hostname]/ e rinominata in modo che corrisponda al percorso di contesto dell'applicazione. Una volta che questo file esiste, non verrà sostituito se una nuova GUER con un nuovo /META-INF/context.xml viene inserita nell'appbase dell'host.

Tuttavia ho notato che se metti nuovo file di guerra nella directory webapp, il context.xml in META-INF directory sostituisce context.xml in $CATALINA_BASE/conf/[enginename]/[hostname].

Esiste una configurazione che assicura che context.xml in $CATALINA_BASE/conf/[enginename]/[hostname]/ non venga sovrascritto ogni volta che viene distribuito un nuovo file di guerra.

Edit: Sto usando autodeploy = "true" Dal commento di Josek, capisco quando tomcat vede nuovo file di guerra, undeploys vecchia applicazione (che porta alla cancellazione di file di contesto) e distribuisce il nuovo file di guerra (che porta alla creazione di un nuovo file di guerra). In tal caso le informazioni di cui sopra dal documento Tomcat non sono rilevanti. La nuova domanda può esserci qualche situazione in cui la cosa sopra può accadere?

Answer 1

Se si desidera evitare la sovrascrittura di 'context.xml', è possibile andare a Tomcat Manager url e quindi disinstallare l'app precedente e installare il nuovo war/ear. In questo modo si ha un maggiore controllo sul processo di installazione.

Answer 2

Accetto che la documentazione sia fuorviante. Normalmente, questo comportamento è effettivamente accolto dal momento che quando si distribuisce una nuova versione dell'applicazione, si desidera distribuire anche il file context.xml aggiornato. Se si pianifica di modificare manualmente il file context.xml sul server di produzione, suggerisco di ignorarlo completamente e di copiarne il contenuto nel file conf/server.xml.

Una rapida patch/soluzione al problema (non lo farei personalmente) consiste nel contrassegnare il file context.xml come readonly dopo che è stato distribuito e aggiornato la prima volta. In questo modo Tomcat non può cancellarlo/aggiornarlo.