[Java] Installare librerie non nell'applicazione ma nel server Tomcat e richiamarle

[Shadow976]

Cari utenti,
posto in questo forum in quanto il quesito non riguarda solo la collocazione di risorse in un server ma anche e soprattutto il modo corretto di richiamarle in un'applicazione web.

Parliamo di applicazioni web Java create con Eclipse. Nella mia web application in Java sono contenute alcune librerie, prendiamo ad esempio jasperreport.jar, collocata sotto WebContent/WEB-INF/lib. Deploiando sotto Tomcat remoto, funziona. Ora però vorrei fare in modo che quella pesante libreria non si trovi nella mia applicazione (che misura pochi kilobyte contro i tre mega della libreria!), ma nel servlet container del Tomcat. Così ogni volta che dovrò deploiare una nuova versione della mia applicazione in remoto, dovrò trasferire solo i pochi kilobyte dell'applicazione vera e propria e non anche i mega delle librerie, che tanto sono sempre identiche al variare delle versioni della mia applicazione.

Volendo percorrere questa soluzione, dove collocarla? E in generale, come dire alla mia applicazione di non cercare una generica mylib.jar sotto WEB-INF/lib ma sotto una certa cartella del Tomcat?

Grazie a tutti!

[snakeplinsky]

Le librerie vanno messe sotto la cartella HOME_TOMCAT\common\lib e sono visibili a tutte le applicazioni del gatto

[Shadow976]

Riesumo questa discussione in quanto per alcuni giorni sono stato fuori.

Sotto la mia versione di Apache (6.0.26) non vedo alcuna cartella common; c'è solo una cartella /lib sotto la cartella principale del Tomcat e mettendo le librerie lì non vengono viste. Nello specifico, parlo della libreria Jasper Report.

Grazie comunque per l buona volontà, nessuno ha suggerimenti risolutivi?

Shadow

[valia]

devi modificare il classpath per "dirgli" di cercare anche dentro la cartella di tomcat (in pratica aggiungerla in qualche modo al tuo path.

Io eviterei di scegliere questa soluzione: se la metti nel web container stai supponendo che tutte le applicazioni che ci sono contenute usino la libreria da te inserita nella versione da te inserita, per cui un aggiornamento di una sola libreria comporta l'aggiornamento di tutte le applicazioni che nel web container girano. Dirai ma sono sempre le stesse, e ok ma da me per un progetto vecchio usavo jetty 6 per uno nuovo ho usato la versione più aggiornata e per poter tenere una sola libreria avrei dovuto correggere nuovamente l'applicazione (e far correggere anche ai clienti). Ergo dal punto di vista applicativo (e di manutenzione) tenere fuori lo stretto necessario per me resta la soluzione migliore.

Ancora rifletti sul significato delle cartelle: Tomcat (così come qualsiasi web container) ha bisogno delle sue lib per poter funzionare, quindi la struttura a tree che conosci è necessaria per il corretto funzionamento del web container, non dell'applicazione.
Per le applicazioni c'è uno spazio a loro dedicato (la web root) usato per i mestieri e questo può contenere roba che non è detto che Tomcat abbia (in dettaglio cosa se ne fa Tomcat di Jasper Report?). Logicamente occhio a non mischiare le cose, quello che serve per l'esecuzione del container e quello che serve per l'esecuzione tua.
Oltretutto, a meno che non sei tu il sistemista, i sistemi di hosting ti danno uno spazio, ma di certo non ti danno modo di accedere a locazioni fuori di esso. Infine, anche se è in locale, spesso Tomcat è installato con permessi di root, o esegui ogni cosa con permessi di root, o cambi permessi, o cambi politica.

Sono tante le ragioni per cui Tomcat dovrebbe avere in lib solo lo stretto necessario al suo di funzionamento, non al funzionamento delle applicazioni.

Non so come fai ad escludere il path corrente dalla ricerca visto che è il primo che viene esplorato alla ricerca di una libreria (si presume che hai a portata di mano quello che ti serve) e soprattutto non so quanto senso abbia. La soluzione è includere lib di tomcat nel classpath e farla eseguire da li.

[Shadow976]

Valia grazie per la buona volontà. Avevo già trovato risposte in altre lingue poi provate a tradurre, ma non ne sono venuto a capo.

Il puno è proprio questo: quali operazioni compiere per aggiungere tali risorse nel class path? Da "configure build path" di Eclipse le ho provate tutte, nei pannelli di configurazione si aggiungono, ma poi non le vedo.

Soluzioni?

[valia]

perché usi eclipse per generare le robe che ti servono, lo devi fare a manina (al max con uno script ant, maven).
Eclipse, come ogni IDE, è uno strumento a supporto del programmatore, ma le cose le devi sapere fare anche senza eclipse, significa che il tutto deve funzionare in modo autonomo.

Ora mi dici il contenuto della tua cartella web content (insomma quella di cui fai il deploy)?

[Shadow976]

Caro Valia,
letta la tua risposta e per le stesse necessità sopra rappresentate, visto che mi sconsigli di usare le cartelle del Tomcat per inserire le librerie esterne necessarie al funzionamento della mia web app Java, ho deciso che caricherò un war apposito contenente sole librerie. Sarà come un'altra applicazione, solo che conterrà le librerie necessarie alla mia applicazione vera e propria. Così ogni volta in cui dovrò deploiare qualche versione successiva del mio progetto, dovrò deploiare solo 1,5 mb e non 200 in quanto l'applicazione fittizia con le librerie non verrà mai toccata e resterà sempre sul server (200 Mb che per la cronaca la mia applicazione raggiungerebbe inserendo le librerie, visto che tra poco userò anche Hibernate e Struts!).

Condividi la mia idea? E come fare in modo che la mia applicazione app_my veda l'applicazione contenete le sole librerie app_lib?

Grazie!

[valia]

Prima di tutto, hai provato questo sistema e funziona?
Io spesso opto per la soluzione che fuori sta lo stretto necessario, anche se la mia roba cresce di dimensioni (non sai quanti mal di testa mi hanno fatto venire versioni di poco differenti delle librerie)

[Shadow976]

Mai provato, infatti chiedevo a te qualche consiglio! Sul fatto delle librerie, così come ho posto la soluzione non ci sono più pericoli tra versioni differenti di librerie!

Prima infatti mettendo tutto sotto le cartelle di Tomcat più applicazioni vedevano stesse librerie e si potevano creare conflitti. Ma se ora ho solo le applicazioni myapp_app e myapp_lib, myapp_app sarà fatta in modo che solo lei potrà vedere le librerie in myapp_lib!

Non trovi sia una buona idea? Grazie ancora!

[valia]

chiedevo se lo avessi fatto perché appunto mi viene in mente una roba: ogni web application all'interno del web container conosce SOLO lo spazio lasciato dal web container (eventualmente la tmp o la home), ma come dici tu dovresti

1. creare un war da deployare
2. far riferire alla tua web application il war deployato

ma in linea di principio, la tua web application non esce dal seminato, se ne va nel path di sistema al max, quindi il problema non è risolto (a mio parere).

per la mia esperienza (di persona che ha dovuto manutenere/aggiornare strutture simili) in comune terrei solo lo STRETTO indispensabile, può essere scomodo per ragioni di spazio occupato/dimensione e hai ragione, ma è comodo per manutenzione /gestione dei container.

La tua soluzione funziona se hai invece una struttura particolare:
la tua web application riferisce la una web applicatioin library, hai tutto in un unica root (sempre un unico punto di accesso),ma puoi aggiornare solo la web application e non le librerie. Ma come vedi è un caso particolare dell'"applicazione autocontenitiva" in cui separi applicazione e libreria, ma anche qui a volte ricarimenti generali sono necessari per via di linking corretto delle varie risorse. ergo, il risparmio in questo caso è fittizio.
Se noti questa è la struttura tipica delle applicazioni EE, in cui ti trovi una parte di librerie, una di application utente, una di logica, ma ripeto distribuisci tutto e ti occupi, in caso di update, della riocmpilazione totale per evitare inconsistenze.