Refactoring delle distribuzioni webapp di Tomcat

Question

Refactoring delle distribuzioni webapp di Tomcat

#1 da (2 voti)

2

Sfondo

Abbiamo diverse app Web in esecuzione su Tomcat 7.0.x (su Linux). Per ragioni storiche, abbiamo compilato la lib "comune" (ovvero $ CATALINA_HOME / lib) con molti jar di applicazione. Questi vasi includono Spring, Jackson e i nostri barattoli di persistenza.

Mentre distribuiamo nuovi jar di persistenza, siamo coinvolti in un inferno del classpath: alcuni jar sono OK in ~ / webapps / foo / WEB-INF / lib, ma alcuni devono essere esclusi e posizionati in Common. Le recenti avventure mostrano che alcuni potrebbero dover essere in entrambi i luoghi .

La nostra build locale (Windows) è altrettanto disordinata: abbiamo una cartella piena di barattoli. Costruiamo con Eclipse (non Gradle, Ant, ecc.) E non abbiamo un elenco esplicito di jar usati dalle applicazioni web. La build di Linux usa Ant, ma semi-selettivamente giare nei file WAR.

Domanda

Vorrei scrivere una strategia su come districarci da questa situazione. Un approccio è elencato di seguito, ma gradirei eventuali perfezionamenti o approcci alternativi.

L'obiettivo è correggere il processo di distribuzione, non la build locale.

Strategia

Sul computer locale, usa Gradle per compilare ogni applicazione web:

aggiungi dipendenze in fase di compilazione fino a quando la compilazione è OK
individua la cache locale di Gradle (o osserva l'output) per trovare le dipendenze di runtime transitive
aggiungi tutti i jar a ~ / WEB-INF / lib per l'app Web, con riferimenti espliciti nella build Ant formale
distribuire in un'installazione di Tomcat nuova e pulita
osserva i log di avvio per qualsiasi eccezione "ClassNotFound", sia per le librerie di terze parti che per le nostre librerie di applicazioni
aggiungi queste librerie al form Ant formale
eseguire test QA di regressione su applicazione e monitor per "ClassNotFound"

java deployment tomcat

posta Michael Easter 20.07.2013 - 18:53

fonte

1 risposta

Leggi altre domande sui tag java deployment tomcat

Verifica dello stato valido all'interno della funzione o all'esterno [chiuso] Rest API e dati di memorizzazione nella cache

score 2 · Answer 1

Nella mia esperienza nella creazione di applicazioni che utilizzano Maven per Tomcat 6 e Tomcat 7, non ho mai avuto bisogno di distribuire i jar esplicitamente nella directory di lib comune di Tomcat .

Dai un'occhiata a questo post: link

Le risposte indicano che possono sorgere conflitti tra le classi nella cartella condivisa di lib comune e quelle in ogni applicazione Web, poiché ciascuna applicazione Web può avere dipendenze da versioni differenti.

Inoltre, in base alla pagina Tomcat a cui ci si collegava per le librerie di caricatori di classi comuni: "Normalmente, le classi di applicazione NON dovrebbero essere collocate qui".

Ad esempio, se tu avessi log4j-1.2.15.jar nella directory commons / lib e log4j-1.2.17.jar nella directory lib dell'applicazione, Tomcat potrebbe provare a caricare 1.2.15, mentre la tua applicazione era scritto per utilizzare 1.2.17, che può portare a ClassNotFoundExceptions e potenzialmente altre eccezioni.

Suggerisco di posizionare solo le librerie che Tomcat ha bisogno per se stesso nella directory lib comune e lasciare che ogni contesto applicativo carichi le proprie dipendenze.

Se si utilizza Maven (e si configura correttamente il progetto), non è necessario spostare manualmente i vasi. Gradle potrebbe avere funzionalità simili.