Newsgroup: it.comp.java
Titolo: Tomcat re-deploy

Domanda... per fare il deploy di un mia applicazione copio il file .war 
nella directory webapps e Tomcat/6.0.18 fa tutto il lavoro e rende 
disponibile la mia applicazione.
Ora io vorrei poter aggiornare quell'applicazione sovrascrivendo il .war con 
la nuova versione e mi piacerebbe che tomcat facesse in automatico il deploy 
del nuovo war.
E' possibile questa cosa?
Se lo faccio non funziona piu' nulla!
Se invece copio a mano i singoli .class l'applicazione lavora con la 
versione "vecchia" fino a quando non riavvio il tomcat..

 Se lo faccio non funziona piu' nulla!
Se aggiorni il WAR dentro tomcat/webapp (giusta la cartella?), Tomcat
dovrebbe fare il redeploy. Lo puoi fare anche tramite il Tomcat Manager.
"Non funziona", significa cosa? E' abbastanza noto che dopo alcuni redeploy
Tomcat si pianta. Comunque molto dipende dall'applicazione e dalle librerie usate.
Quindi, ti succede subito o dopo alcuni redeploy?

 Quindi, ti succede subito o dopo alcuni redeploy?
Ad ogni redeploy. Mi spiego meglio..
Io ho gia l'applicazione deployata tramite un miaapplicazione.war. Se 
aggiorno questo war "a caldo" vedo che viene aggiornata anche la cartella 
/miaapplicazione ma quando mi collego con il browser vedo l'errore 404 con
description The requested resource (/miaapplicazione/) is not available.
a questo punto anche se stoppo e faccio ripartire il tomcat da sempre questo 
errore.
Devo cancellare la cartella /miaapplicazione e far ripartire il tomcat che 
fa il deploy da zero e allora tutto torna a posto..



Il log di Tomcat potrebbe darti qualche utile informazione sul perche' di cio'.

 versione "vecchia" fino a quando non riavvio il tomcat..
E' il comportamento corretto, anche se basta riavviare l'applicazione, 
non tutto il server.
Personalmente evito (e sconsiglio) di collocare le applicazioni dentro 
webapp ma piuttosto ritengo opportuno usare directory esterne al server.
Configurando adeguatamente il file server.xml (tag context con attributo 
docBase che punta alla directory dell'applicazione e corretta 
impostazione dell'attributo reloadable) si ottiene maggior chiarezza, 
minor "invasività" sul server e parametri/configurazione più espliciti.

 minor "invasività" sul server e parametri/configurazione più espliciti.
Nei casi in cui sia possibile usare con successo reloadable="true"potresti 
anche avere ragione sulla convenienza. 
Comunque non capisco cosa intendi con "invasività", e "parametri/configurazione
piu' espliciti".

 piu' espliciti".
Parlo di "invasività" quando ho a che fare con molti sviluppatori (di 
cui alcuni magari non espertissimi) che lavorano su una o più 
applicazioni collegate: preferisco che non vadano tutti a mettere le 
mani su file e directory di tomcat per ogni minima modifica ma che si 
limitino a lavorare nel loro ambiente.
La configurazione più esplicita la riscontro quando nel tag del context 
aggiungo i sotto-tag o attributi "resource", "log" e simili (anche 
questi fissati a priori e modificabili solo dai capi progetto).
Certo si tratta di preferenze personali e soggettive, anche se negli 
anni mi hanno evitato qualche seccatura (che invece ho riscontrato 
spesso negli ambienti troppo "liberi" a livello di permessi di 
accesso/configurazione) :)

 Prima di sostituire il file war stoppi l'applicazione?
Ma si, ho provato sia stoppando che no. Se fa il re-deploy poi non funziona 
piu' nemmeno riavviando il server. Devo stoppare il tomcat, cancellare la 
cartella dell'applicazione e avviare il tomcat (cosi' praticamente fa un 
deploy ex-novo..)