2009-06-26 13 views
1

In unserem Shop verwalten wir ungefähr 20 Java EE-Webanwendungen. Die meisten dieser Anwendungen sind in ihrer Architektur ziemlich CRUD-ähnlich, wobei einige von ihnen ziemlich rechenintensive Berechnungsanwendungen sind.Java EE Jar-Dateifreigabe

Für die Bereitstellung dieser Anwendungen haben wir Hudson zur Überwachung unseres CVS-Repositorys eingerichtet. Wenn wir einchecken, werden die Projekte kompiliert und auf unserem Tomcat 6.0-Server (Solaris 10, Sparc Dual-Core-Prozessor mit 1,6 GHz, 2 GB RAM ... nicht die beängstigendste Maschine in jedem Bereich der Imagination ...) und, wenn für das Projekt Unit-Tests vorhanden sind, werden diese ausgeführt und das Projekt wird nur implementiert, wenn die Unit-Tests bestanden werden. Das funktioniert großartig.

Jetzt, im Laufe der Zeit, habe ich mich selbst bemerkt, dass viele der Projekte, die ich erstelle, die gleichen .jar-Dateien immer wieder verwenden (Hibernate, POI (Excel-Ausgabe), SQL Server JDBC-Treiber, JSF, ICEFaces, Geschäftslogik .jar-Dateien usw.). Unsere Praxis bestand darin, einen Ordner auf unserem Netzwerklaufwerk mit allen Standard-.jar-Dateien, die wir verwendet haben, zu speichern, und wenn ein neues Projekt gestartet wird, kopieren wir diesen Satz von .jar-Dateien in das neue Projekt und gehen von dort. ..und ich fühle mich so schmutzig jedes Mal, wenn dies passiert, hat es begonnen, mich nachts aufzuhalten. Ich habe von meinen Mitarbeitern erfahren, dass es "extrem schwierig" ist, ein .jar-Repository auf dem Tomcat-Server einzurichten, das ich für eine Sekunde nicht kaufe ... Ich schreibe es der reinen Faulheit zu und, wahrscheinlich, kein Wunsch, die beste Praxis zu lernen. Ich könnte mich irren, aber ich sage nur meine Gefühle zu diesem Thema. Dies scheint die Größe unserer WAR-Dateien aufzublähen, die ebenfalls auf dem Server bereitgestellt werden.

Aus meiner Sicht verfügt Tomcat über eine Reihe von .jar-Dateien, auf die alle Anwendungen zugreifen können. Daher würde ich meinen, dass wir alle diese doppelten .jar-Dateien in all unseren Projekten konsolidieren und verschieben könnten sie auf den Tomcat-Server. Dies würde bedeuten, dass nur eine .jar-Datei auf dem Server aktualisiert wird, wenn wir beispielsweise die .jar-Dateien von ICEFaces auf eine neue Version aktualisieren müssen.

Ein anderer Teil von mir sagt, dass ich, indem ich nur eine Kopie der .jar-Dateien auf dem Server einfüge, auch eine Kopie des lib-Verzeichnisses des Servers in meiner Entwicklungsumgebung behalten muss (dh diese .jar-Dateien in Finsternisabhängigkeit).

Mein Bauchgefühl sagt mir, dass ich diese duplizierten .jar-Dateien auf den Server verschieben will ... wird das funktionieren?

Antwort

2

Ich denke, Maven und Ivy wurden geboren, um JAR-Abhängigkeiten zu verwalten. Vielleicht werden Sie feststellen, dass diese hilfreich sind.

Was die Debatte über die Duplizierung der JARs in jedem Projekt gegenüber dem Server/lib betrifft, denke ich, es hängt von einem Punkt ab: Wie wahrscheinlich ist es, dass Sie jede einzelne Anwendung auf Tomcat aktualisieren möchten gleichzeitig? Können Sie sich jemals eine Zeit vorstellen, in der möglicherweise N Apps auf diesem Server laufen und die (N + 1) -te App eine neuere Version einer bestimmten JAR haben oder benötigen könnte?

Wenn es Ihnen nichts ausmacht, alle Apps synchron zu halten, müssen Sie auf jeden Fall eine gemeinsame Bibliotheksbasis verwenden.

Persönlich denke ich, dass Speicherplatz ist billig. Ich bevorzuge es, JARs für jede App zu duplizieren und sie in die WAR-Datei zu legen. Ich mag die Partitionierung. Ich würde gerne mehr davon sehen, wenn OSGi mehr Mainstream wird.

1

Es funktioniert die meiste Zeit, aber Sie können in ärgerliche Situationen geraten, in denen das in Tomcat verschobene jar versucht, eine Instanz einer Klasse in einem Ihrer Webanwendungs-Jars zu erzeugen, was zu ClassNotFoundException s führt . Ich habe das gemacht, aber wegen dieser Probleme gestoppt.

1

Ich glaube wirklich nicht, dass das Verbreiten von Bibliotheken in/lib eine gute Idee ist. Die Idee hinter der Verwendung von War-Dateien als Anwendungen in einem Servlet-Container besteht darin, eine echte Idee der Isolation zwischen Ihren Webapps zu haben. Sie könnten Fehler wie die Bereitstellung einiger WAR-Dateien von Drittanbietern (mit eigenen Bibliotheken innerhalb von WEB-INF/lib) erleiden und sich unerwartet verhalten, weil sie eine andere Version einer dieser Bibliotheken aus dem allgemeinen geladen hat (denken Sie daran, dass das normale Verhalten für Ladeklassen ist) Schauen Sie sich zuerst den normalen Classloader an und wenn Sie die Klasse nicht finden, schauen Sie sich den für Ihre Webapp an. Erwähne nicht einmal, wie schmerzhaft es sein kann, eine Anwendung in einen anderen Servlet-Container oder einen Application Server zu verschieben. Wie bereits erwähnt, könnten Sie maven verwenden, um mit Jar-Abhängigkeiten umzugehen, und wenn Sie die homogene Verwendung von Bibliotheken mögen, definieren Sie einen POM-Parent (Maven-Jargon) für alle Ihre Anwendungen.

1

Nach meiner Erfahrung sollten Sie sehr vorsichtig mit der Freigabe von Bibliotheken zwischen Webanwendungen sein, indem Sie sie in den Webcontainer selbst verschieben.

Lassen Sie sie in WEB-INF/lib leben, damit Ihre Kriege in sich abgeschlossen sind (Sie werden froh sein, dass Sie es eines Tages getan haben).

Was Sie in Erwägung ziehen könnten, ist die Verwendung von Maven oder Ant Ivy, um stattdessen Bibliotheksgläser aus einem gemeinsamen Repository zu holen. Dies ist sehr nützlich und sollte in Ihrem Szenario kein Problem darstellen.


Edit: Eine bemerkenswerte Ausnahme ist die Metro-Bibliothek - Web-Service-Schicht aus Glasfischen - die im Web-Containern sein muss und nicht in der Web-Anwendung.