Se distribuisco un file di guerra su Tomcat, chiamato ad esempio foo-bar-1.1.2.war , come posso distribuirlo in modo che venga estratto in webapps / bar e la sua radice URL sia / bar / … ?
La mia intenzione qui è di mantenere il file war nel server webapps con le sue informazioni sulla versione in modo da sapere quale versione è installata ma sovrascrivere una versione precedente dell’app.
Potrei distribuire il file di guerra usando PSI Probe . Questo mi permetterebbe di specificare un contesto di destinazione per l’app web. Tuttavia, vuol dire che perderei qualsiasi informazione sulla versione nel nome del file war.
Tomcat estrae sempre il contenuto di un file di guerra, in una cartella con lo stesso nome (quando è configurato per distribuire i conflitti – come predefinito, ecc.).
Puoi estrarlo in un nome di cartella a tua scelta. Quindi se decomprimi il contenuto di foo.war in una cartella chiamata bar/ manualmente, invece di lasciar cadere la guerra nella cartella web apps, caricherà comunque l’applicazione web.
Tuttavia, questo è del tutto inutile in quanto è ansible specificare il modello di URL dell’applicazione senza incasinare la cartella / il nome del file war ignorando l’elemento root di contesto per la propria applicazione:
Questo è spesso impostato su Tomcat server.xml , ma questa pratica è abbastanza ampiamente scoraggiata. Invece, ti suggerirei di usare context.xml nella cartella META-INF della tua applicazione web / file di guerra:
Quando l’applicazione viene distribuita, il context.xml deve essere copiato in /conf/Catalina/localhost ma rinominato in foo.xml
Si noti che le radici di conext devono essere univoche e ci sono alcune considerazioni aggiuntive se si stanno utilizzando le operazioni autoDeploy o deployOnStartup (Source http://tomcat.apache.org/tomcat-7.0-doc/config/context.html ).
Altre opzioni includono:
foo-1.1.0 . foo/version1 È anche ansible utilizzare Ant (o uno strumento equivalente) per automatizzare le distribuzioni (ed eseguire una delle operazioni precedenti).
C’è un punto importante da sottolineare sull’attributo path della definizione del frammento di contesto. Per citare la documentazione sull’argomento :
Quando le operazioni autoDeploy o deployOnStartup vengono eseguite da un host, il nome e il percorso di contesto dell’applicazione Web derivano dai nomi del / dei file che definiscono (s) l’applicazione web.
deployOnStartup è il comportamento predefinito degli host Tomcat .
Per seguire la documentazione, questo ha una conseguenza molto importante:
il percorso di contesto non può essere definito in un
META-INF/context.xml
Secondo i modi di definire un contesto Tomcat , questo consente solo due soluzioni:
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory Inside a Host element in the main conf/server.xml , cos’è una soluzione scoraggiata in un ambiente di produzione in quanto richiede il riavvio del server Un’altra soluzione sfrutta l’ attributo unpackWARs .
Dal mio punto di vista, per questi motivi, il modo semplice e generale per implementare un percorso sottile in un ambiente di produzione sta prendendo piede sulla denominazione dei file war (cosa che potrebbe includere la gestione delle versioni e una soluzione al problema). Un singolo sharp (es. Test # path.war ) nei nomi dei file war implica un segmento nel percorso di contesto (ad esempio / test / percorso ). Un doppio tagliente introduce il numero di versione (ad es. Test # path ## 112.war ). Funziona indipendentemente dal fatto che il disimballaggio dei file di guerra, l’implementazione a caldo o meno, sia indipendente dalla distribuzione (gestore o file system) e gestisce versioni multiple di uno stesso archivio.
Ma se c’è la necessità di avere un percorso distinto dal nome dell’archivio, sembra che l’unica soluzione sia il descrittore nella directory /conf/[enginename]/[hostname]/ o nel file server.xml . Per questi, è necessario un accesso al filesystem del server.
La soluzione pertinente è strettamente correlata al modo in cui Tomcat è configurato e gestito quotidianamente.
Se si desidera includere solo le informazioni sulla versione nel nome del file war, è ansible denominarlo come: my-app##1.2.3.war . Viene decompresso nella directory my-app##1.2.3 ma il contesto sarà solo la my-app (ovvero http: // host / my-app / ).
Funziona almeno con Tomcat 7.0.55