Attualmente sto lavorando a un'applicazione che ha circa un decennio. Quando ho esaminato i file jar associati all'applicazione, posso vedere molti jar non necessari e molte versioni diverse dello stesso jar.File jar indesiderati in tomcat/lib o WEB-INF/lib
Quali sono i vantaggi di avere giare indesiderati in lib. Qual è il modo più semplice per trovarli e rimuoverli?
È possibile che si verifichino problemi se un programma di caricamento classi decide di caricare classi da una versione di file jar diversa da quella prevista. Questi tipi di problemi sono solitamente difficili da rintracciare. Il server controllerà i file in ordine specifico (in ordine alfabetico per nome file?) E utilizzerà la prima classe/risorsa corrispondente trovata. Probabilmente non ci sono garanzie che la versione più recente di un file jar sia vista per prima.
Non so di strumenti che possano scoprire quali barattoli sono inutilizzati. Ciò potrebbe essere impossibile in generale a causa della riflessione, ma un certo grado di controllo automatico dovrebbe essere possibile, almeno in teoria.
La rimozione del file jar inutilizzato per tentativi ed errori è problematica se non si dispone di buoni test di unità, cosa di cui dubito si abbia in un'applicazione vecchia di decenni. Ci può sempre essere qualche raro caso di errore che dipende solo dalla vecchia versione di jar appena rimossa.
Ok fantastico .. Grazie. – Umesh
Con i file jar indesiderati nell'applicazione, si intende che questi vengono generati come parte del processo di compilazione e generazione ogni volta? In tal caso, potrebbero essere gli script di build da ripulire.
Se si fa riferimento all'ambiente di distribuzione effettivo, è necessario eseguire con molta attenzione qualsiasi operazione di pulizia. Perché non provare a ricominciare da capo in un nuovo ambiente di test con un'installazione di tomcat pulita e gli eseguibili della build più recente distribuiti? Vedi se funziona bene solo su quello, e se lo fa, allora forse i barattoli in più sono davvero inutili.
Per quanto riguarda gli svantaggi, non vedo nulla a parte la dimensione della distribuzione.
ciò che intendevo per i jar indesiderati è jtds1.2.jar e jtds1.2.2.jar è lì dove 1.2 non è usato. Stiamo usando il tipo di connessione Jtd per gli ultimi sei mesi. Ma contiene ancora il file mssql.jar, ecc. Che prima si stava usando. Non ci sono file generati come parte di compilazione/compilazione. – Umesh
Come si può decidere quale dei vasi non viene utilizzato effettivamente?
Suggerirei di fare di questo un cambio completo di QA. Non hai idea se il codice scelto dall'insieme di barattoli offuschi un'imprevedibile superficie di implementazione se rimuovi un vaso "obsoleto".
Il mio suggerimento è che se le vostre applicazioni stanno funzionando, lasciate i barattoli come sono adesso. Sarà molto difficile se non impossibile da scoprire, quali file jar vengono effettivamente prelevati dal programma di caricamento classi. (Ovviamente non distribuire nuove applicazioni).
È possibile trovare i pacchetti contenenti un file jar utilizzando JarAnalyzer. Questo ti darà un'idea dei duplicati e potrai iniziare a rimuovere le versioni precedenti dei file jar. Tuttavia questa procedura deve essere eseguita a mano e per tentativi ed errori. Inoltre, lo stesso pacchetto può essere contenuto in due vasi con nomi diversi e senza informazioni sulla versione.
Come già detto, avere versioni diverse dello stesso barattolo potrebbe causare il caos. Non puoi sapere quale versione verrà effettivamente utilizzata e quali conflitti porteranno a questa o ad un'altra applicazione. Ecco perché non dovresti mai usare la cartella condivisa di Tomcat per i barattoli delle applicazioni. Se ci si trova in una situazione in cui molti file jar sono posizionati nella cartella condivisa, evitare di utilizzare questo server per nuove applicazioni.
Per ora ho solo un'applicazione in esecuzione sotto il tomcat. Ma il motivo per includere i jar nel percorso condiviso di tomcat è, alcuni jar che Tomcat non prenderà mentre residente nella lib dell'applicazione. Es: jtds.jar, mysql v 5.4 jar. Se metti questi jar nella lib dell'applicazione e provi a connetterti al database, genererà un'eccezione. (Non ha mai funzionato per me. Per una soluzione, l'ho copiato su tomcat lib e ha iniziato a funzionare.) – Umesh
Se si sta utilizzando una risorsa JNDI per configurare un'origine dati, il connettore jdbc deve essere nella cartella condivisa, in modo che il file jar è presente prima dell'avvio dell'applicazione. Questa è un'eccezione alla regola. Non posizionare vasi nella cartella condivisa, a meno che ciò sia assolutamente necessario. – kgiannakakis
Penso che intendessi "contro", non "crons". Siamo spiacenti, nessun privilegio di modifica ancora. – DVK
cambiato! e tutto il meglio per averlo presto! – Umesh