Perché tomcat sostituisce context.xml su redeploy?

documentazione dice che se si dispone di un file di contesto qui:Perché tomcat sostituisce context.xml su redeploy?

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

non sarà sostituito da un file di contesto qui:

mywebapp.war/META-INF/context.xml

È scritto qui: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

Solo se un file di contesto non esiste per l'applicazione in $ CATALINA_BASE/conf/[nomemile]/[nomehost] /, in un singolo file in /META-INF/context.xml all'interno del file dell'applicazione es.

Ma ogni volta che ri-distribuire la guerra sostituisce questo myapp.xml con la /META-INF/context.xml!

Perché lo fa e come posso evitarlo?

Thanx

fonte

2010-10-27 artemb

Si distribuisce manualmente o tramite un plug-in IDE? – BalusC

Personalmente, non metterei un context.xml sul server dell'app. Non lo faccio perché raramente posso dipendere dall'avere accesso a quel file. Di solito lo tengo locale nel mio file WAR. – duffymo

Sto distribuendo manualmente inserendo mywebapp.war in $ CATALINA_HOME/webapps. Mantengo le mie impostazioni predefinite in WAR, ma voglio essere in grado di modificare tali impostazioni su una singola istanza senza modificare la guerra stessa - è per questo che voglio il mio contesto nella directory conf invariato – artemb

Undeploy parte di ridistribuire elimina applicazione e il context.xml associato.

Se si utilizza Tomcat Maven plugin che si può evitare di cancellare context.xml se si distribuisce la vostra applicazione con il comando in questo modo:

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

Maggiori informazioni qui: http://mojo.codehaus.org/tomcat-maven-plugin/deploy-only-mojo.html

È possibile utilizzare distribuire solo con modalità parametro per distribuire anche il contesto.xml.

fonte

2011-12-12 10:05:12 petro

Per chi segue a casa: 'mvn tomcat7: deploy-only -Dmaven.tomcat.update = true -Dmaven.tomcat.mode = both -Dmaven.tomcat.contextFile =/foo/context.xml' fa il trucco. Triste ... ma efficace in tomcat7. –

Su tomcat7, anche con autoDeploy = falso il file verrà eliminato in undeploy. Questo è documentato e non un bug (sebbene eviti le buone distribuzioni automatizzate con configurazione fissa lato server).

ho trovato una soluzione che ha risolto il problema per me:

creare un file/context.xml META-INF nella tua webapp che contiene
sul server di creare un secondo contesto "/ config contesto "in server.xml e mettere lì tutti i parametri di configurazione lato server
sull'applicazione utilizzare context.getContext ("/config-context "). getInitParameter (...) per accedere alla configurazione lì.

Ciò consente una configurazione per host indipendente dalla guerra dispiegata.

Dovrebbe anche essere possibile aggiungere configurazioni per contesto aggiungendo contesti come "/ config-context-MYPATH". Nella tua app puoi utilizzare il percorso di contesto o l'app per calcolare il percorso di contesto dell'app di configurazione.

fonte

2012-10-04 15:24:27

Perché gli sviluppatori di tomcat core sono così ignoranti nell'implementazione delle best practice? Ho perso praticamente una notte per avere una soluzione qui e tutti i work around sono anti-pattern, ma gli sviluppatori di TC sono in diniego e non riconoscono che questo è un approccio ragionevole per installare i sorgenti e le sorgenti JNDI sull'host, non compilare loro nel SCM e nella guerra. https://issues.apache.org/bugzilla/show_bug.cgi?id=34840 –

La risposta breve:

Basta fare il TOMCATHOME/conf/Catalina/localhost dir sola lettura, e continuate a leggere per maggiori dettagli:

Per modalità di implementazione rapida (Progetto Web dinamico Eclipse, connessione diretta Tomcat , ecc.) Su un server Tomcat locale/non condiviso, è possibile definire l'origine dati JDBC (o qualsiasi altra risorsa Web ) utilizzando lo META-INF/context.xml file all'interno del file WAR . Facile e veloce nel tuo ambiente locale, ma non adatto alla produzione in scena, QA o produzione .
Per modalità di implementazione accumulo (di solito per la stadiazione, QA, o prod), JDBC origini dati e dettagli altre 'risorse web' sono definiti dal team QA/di produzione, non il team di sviluppo più. Pertanto, è necessario specificare nel server Tomcat, non più nel file WAR . In questo caso, specificarli nel file TOMCATHOME/conf/Catalina/localhost/context.xml (cambiamento Catalina dal motore, e localhost dall'host, e CONTESTO dal proprio contesto di conseguenza) . Tuttavia, Tomcat eliminerà questo file in ogni distribuzione. Per evitare questa cancellazione di , basta impostare questa directory in sola lettura; in Linux è possibile digitare:
```
chmod a-w TOMCATHOME/conf/Catalina/localhost 
```
Voila! Prego.

La risposta lunga

Per ragioni storiche Tomcat consente di definire le risorse web (origini dati JDBC, e altri) in quattro luoghi diversi (leggere quattro diversi file) in una specifica ordine di precedenza, se ti capita di definire la stessa risorsa più volte. Quelli nominati nella risposta breve qui sopra sono i più adatti al giorno d'oggi per ogni scopo, anche se potreste ancora usare gli altri (nah ... probabilmente non lo volete). Non sto andando a discutere gli altri qui a meno che qualcuno non lo chieda.

fonte

2015-03-19 18:00:06 user4691115

Lo chiederò ;-) – djKianoosh

Questo non funzionerà quando autodeploy è attivo per tomcat e tu usi tomcat7: undeploy si lamenterà che non è possibile eliminare il file descrittore di contesto – Chad

Con questa opzione, i miei deploy non riescono con il messaggio di errore "Impossibile richiamare il gestore Tomcat: connessione ripristinata" per il motivo indicato nel commento di Chad. Invece, ho usato l'opzione usando context.xml da WEB-INF e la risorsa jndi opzionale (esterna) dal server.xml come descritto nella prima risposta [qui] (http://stackoverflow.com/questions/7142365/how-to-provide-a-context-configuration-for-a-web-application-in-tomcat) – tareq

Secondo la documentazione (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) su Tomcat redeploy rileva la cancellazione (undeploy) della vostra applicazione. Quindi inizierà un processo di pulizia eliminando anche la directory e xml. Questo è indipendente dall'implementazione automatica - quindi avverrà in caso di ridistribuzione tramite gestore e modifica di guerra.Ci sono 3 eccezioni:

risorse globali non vengono mai cancellati
risorse esterne non vengono mai cancellati
se la guerra o DIR è stato modificato il file XML viene cancellato solo se copyXML è vero e deployXML è true

Non so perché, ma copyXML = "falso" deployXML = "falso" non aiuta.

In secondo luogo: la lettura della directory consente solo a Tomcat di generare un'eccezione e di non avviarsi.

Si può provare a fondere il vostro $ CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $ CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml, ecc file in $ CATALINA_BASE/conf/context.xml (che funziona solo se si assicura che l'applicazione non distribuirà la propria configurazione di contesto, come myapp-1.xml)

Se qualcuno potrebbe dire quali sono quelle "risorse esterne" che in genere risolverebbero il problema.

fonte

2015-11-10 22:45:58 BTakacs

Ridistribuzione significa due parti: disoccupazione e dispiegamento.

Undeployment rimuove il conf/Catalina/yourhost/yourapp.xml perché il

<Host name="localhost" appBase="webapps" unpackWARs="true" 

      autoDeploy="true">  <!-- means autoUndeploy too!!! --> 

</Host>

Modificare il autoDeploy="false" e Tomcat ha nessun ordine più per rimuovere il conf/Catalina/yourhost/yourapp.xml.

fonte

2017-02-15 22:25:01

Perché tomcat sostituisce context.xml su redeploy?

risposta

Problemi correlati