2015-06-03 11 views
7

Ho riscontrato problemi con il modo in cui tomcat distribuisce i miei file sul server.Tomcat non distribuisce affatto la nuova versione di file - linux/eclipse

Ho installato Tomcat 7 su /opt/tomcat7.

Nella mia eclissi ho specificato questo percorso come il mio server tomcat.

mia directory di lavoro è /home/maciej/workspace/<projects here>

ora se modifico un file di classe e aggiungo semplicemente accedere dichiarazione

log.info("blabla"); e quindi distribuire 'NUOVO' versione del file via - eseguito su server i non vedo questo 'blabla' nella mia uscita. Sembra che anche se ho modificato il file di classe, non è stato correttamente distribuito in tomcat. Tomcat sta leggendo Dio sa cosa, ma certamente non il file che dovrebbe leggere.

EDIT: Ho recofnigured il mio gatto in Eclipse e ora:

Server Path = /opt/tomcat7 
Deploy Path = /opt/tomcat7/webapps <- used to be .metadata/blablabla default 
             eclipse tomcat location 

Quando apro 'Apri configurazione pranzo' sotto argomenti/l'opzione di default directory di lavoro è biglietto con in grigio percorso /home/maciej/Desktop

Anche questo dovrebbe essere modificato?

Non è la directory di lavoro Tomcat /opt/tomcat7/work?

Eventuali suggerimenti/idee? Poiché questo problema mi sta leggermente a cuore perché non riesco a sviluppare l'app.

risposta

1

Il Server Path è lo stesso del Tomcat installation directory nella modale che si vede in Window>Preferences>Server>Runtime Environments dopo aver colpito Edit. Deve essere impostato su /opt/tomcat7 o ovunque risieda la root della tua installazione Tomcat.

Il Deploy Path è relativo allo Server Path. Dovrebbe essere webapps, a meno che tu non abbia già del materiale lì e tu voglia una directory separata. Non potrai modificarlo finché non chiudi Tomcat e rimuovi tutte le applicazioni web sotto di esso attraverso la vista Servers.

Provare a deselezionare lo Modules auto reload by default se si ha fiducia nello scambio a caldo di JDK, che si dovrebbe se si utilizza JDK 1.7 o 1.8 e si desidera semplicemente vedere una dichiarazione di registro inserita.

La directory di lavoro che hai citato è solo la directory radice che Tomcat usa per sputare discariche di dump su arresti anomali e simili. Non ha nulla a che fare con la directory "lavoro" di Tomcat.

0

Aprire la vista server: Finestra-> Mostra vista-> Altro-> Server. Selezionare il server corretto, fare clic con il tasto destro, selezionare "Pulisci" e quindi riavviare Tomcat. Dovrebbe aiutare

+0

Ok, quindi in un certo senso risolve il problema. Ma sembra che devo fare questo processo ogni volta che voglio ri-distribuire la mia app e che non è desiderato. Perché dopo il ripiegamento di tomcat non si pulisce da solo? La mia macchina Windows non ha avuto quel problema, ma il mio Linux lo fa. –

+0

Controllare la configurazione di quel server. Appare dopo aver fatto doppio clic su di esso. – JiriS

+0

Ok così ho cambiato la configurazione così ora sto usando il mio tomcat completamente per distribuire la webapp. Così ho impostato il percorso di distribuzione come/opt/tomcat7/webapps e percorso del server come/opt/tomcat7 .... Eppure ancora Tomcat non sta implementando una nuova versione del file in webapps –

0

Se si modifica qualcosa nel progetto, Eclipse verrà creato automaticamente e "distribuito" i file nella posizione specificata. Per impostazione predefinita, il lavoro di Eclipe si ferma lì e il resto è pronto per il tomcat.

Tomcat, come qualsiasi server Web Java, rileva le modifiche in JSP e le ricompone. Tuttavia, i cambiamenti nelle classi non hanno alcun effetto a causa del modo in cui funziona il caricamento della classe Java. Per la nuova versione di una classe che deve essere utilizzata da Tomcat è necessario:

  1. Non aver caricato la classe prima. Ad esempio, si avvia tomcat, ma viene visualizzato un errore prima di eseguire qualsiasi richiesta. Se si modifica la classe, tale modifica verrà utilizzata poiché la classe non è stata ancora caricata.
  2. Ricaricare l'applicazione. Ciò significa che tutte le classi vengono scartate e tutto inizia fresco.

Il modo più semplice per ricaricare un'applicazione, per impostazione predefinita, è apportare una modifica a web.xml. Se si esamina la configurazione di Tomcat conf/context.xml, è possibile verificare che WEB-INF/web.xml sia monitorato. Qualsiasi modifica attiverà una ricarica del contesto. In questo modo è possibile apportare modifiche artificiali al file o aggiungere una risorsa come WEB-INF/version.properties e generare un diverso version.properties con qualsiasi build.

In ogni caso, il ricaricamento di un'applicazione complessa richiede tempo. Ecco perché ci sono plugin come JRebel.Ma prima di andare su quel percorso (che aggiunge un altro pezzo in movimento al tuo setup) puoi anche provare ad usare il supporto di Eclipe per la sostituzione del codice caldo. Si avvia tomcat in debug, ci si connette ad Eclipse e poi si cambia classe. Eclipse proverà a ricompilare la classe e a caricare la nuova definizione su tomcat. Se fallisce te lo dirà. Come regola generale, fallirà quando cambi la struttura del programma e avrai successo quando cambi le implementazioni del metodo.