Perché a tomcat piace eliminare il mio file context.xml?

Sto sviluppando un'applicazione Java basata sul web al lavoro e (ovviamente) devo eseguirla localmente durante lo sviluppo. Ho capito i documenti Tomcat e ho un file context.xml adatto /etc/tomcat6/Catalina/localhost/ma ogni tanto Tomcat decide di cancellarlo! Ciò significa che devo ripristinarlo e riavviare Tomcat.

Perché fa questo? Ho cercato i documenti Tomcat al riguardo e non sono affatto più saggio.

(Oh sì: in realtà non viene chiamato context.xmlma owners.xmlè il prefisso del percorso HTTP per questa applicazione.)

Aggiornare

Ho visto Tomcat eliminare il file mentre Tomcat era in esecuzione . Penso di dover presentare un bug ...

Riepilogo rapido : esistono diverse condizioni (come la modifica del file di guerra, l'eliminazione della webapp o la sua sostituzione con un nuovo contenuto) in base alla quale tomcat dislocare il contesto, inclusa la rimozione del file di contesto.

Dettagli : se tomcat esegue o meno autoDeployment (significa verificare la presenza di modifiche nel descrittore .xml e verificare le modifiche nella directory di webapp) è guidato da:

1. server.xml localted nella sezione $ CATALINA_HOME / conf / server.xml:

   <Nome host = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = "true" xmlValidation = "false" xmlNamespaceAware = "false">

2. È inoltre possibile impostare questa proprietà nel file di contesto sovraccaricando il valore

Citando il documento per i casi in cui autoDeploy = true può causare la rimozione del file di contesto:

• L'eliminazione di un file WAR attiverà la mancata distribuzione dell'applicazione con la rimozione di qualsiasi directory espansa, file di contesto e directory di lavoro associati .
• L'eliminazione di una directory attiverà una mancata distribuzione dell'applicazione con la rimozione di qualsiasi file di contesto e directory di lavoro associati .
• L'aggiornamento di un file WAR attiverà la mancata distribuzione dell'applicazione con la rimozione di qualsiasi directory espansa, file di contesto e directory di lavoro associati .
• L'aggiornamento di una directory (non il contenuto della directory) attiverà la mancata distribuzione dell'applicazione con la rimozione di qualsiasi file di contesto e directory di lavoro associati .

Dettagli esaustivi : http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment

Se non si desidera AutoDeploy funzione , ad esempio negli ambienti di produzione, è possibile considerare i seguenti attributi nel file di contesto conf / Catalina / localhost:

• autodeploy = "false"
• e deployXML = "false"

autoDeploy = "false" potrebbe non funzionare da solo perché l'applicazione context.xml (in META-INF) può sovrascrivere le impostazioni server.xml di autoDeploy.

• Il META-INF / context.xml dell'applicazione verrà utilizzato nell'ambiente di sviluppo, con autoDeploy
• Il contesto conf / Catalina / localhost in produzione, senza AutoDeploy.

documentazione dell'attributo deployXML pena leggere la dell'attributo (§ Implementazione standard).

Caso utente AutoDeploy esauriente e quando il contesto viene rimosso: l'applicazione non distribuita, il caso utente è documentato può essere trovato qui .

Non posso rispondere al perché bit .

Tuttavia, questo collegamento indica che è possibile interrompere l'impostazione impostando autoDeploy="false"inserver.xml

Onestamente non so quale sia il ragionamento alla base di Tomcat, ma prova ad aggiungere il seguente attributo XML al tuo elemento di contesto

reloadable="false"

Quindi il tuo contesto potrebbe assomigliare a questo:

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

Ciò dovrebbe impedire a Tomcat di eliminare il file

Mi rendo conto che questo è un vecchio thread, ma ho pensato di condividere ciò che ho trovato per risolvere questo problema ...

Avevo avuto lo stesso identico problema con il mio file context.xml per la mia versione desktop di Tomcat che veniva bloccato ogni volta che avrei distribuito una nuova copia del file di guerra per la mia applicazione.

Il problema era dovuto al fatto che stavo apportando modifiche a questo file direttamente sul filesystem. Ciò che risolveva il problema era modificare il file context.xml tramite il mio editor Eclipse. All'interno del mio Eclipse, c'è un progetto "server" che una volta espanso, puoi vedere una manciata di file, come context.xml e server.xml. Sembra che se si modificano i file da qui invece di uscire nel filesystem, le modifiche vengono mantenute.

Ho trovato questa soluzione nel seguente thread: https://www.liferay.com/community/forums/-/message_boards/message/16511799

Spero che questo aiuti qualcun'altro!

-StephenS

Il problema generale come descritto dal titolo è coperto dal re-deploy dalla guerra senza cancellare il contesto che è ancora un problema aperto in questo momento.

Esiste una distinzione riconosciuta tra la nuova distribuzione che non elimina il contesto e la distribuzione dopo la mancata distribuzione in cui la mancata distribuzione elimina il contesto. La documentazione non era aggiornata e la GUI del gestore non supporta ancora la distribuzione.

A volte è necessario avere valori diversi per l'app nel server, ad esempio un percorso per archiviare i file caricati. Nell'ambiente di sviluppo mabe abbiamo qualcosa del genere:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

Ma nel server il percorso è diverso:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

Ho anche lo stesso problema, Tomcat elimina il context.xml (meapp.xml) da conf / Catalina / localhost

Per risolvere io uso context.xml.default, nello stesso percorso creo un file chiamato context.xml.default e all'interno di una configurazione put che voglio tenere:

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

Quindi, quando si ridistribuisce quindi l'app, i parametri di conferma sono ancora lì.