Einen Anwendungskontext zwischen zwei WARs freigeben?

Der allgemeine Zweck eines Webanwendungscontainers wie Tomcat besteht darin, dass jede Anwendung unabhängig ausgeführt werden kann (so können Sie einzelne Apps stoppen und starten, ohne andere zu beeinträchtigen), was bedeutet, dass wahrscheinlich viel Aufwand in sie investiert wurde Entwicklung, um Sie daran zu hindern, dies zu tun. Selbst wenn Sie eine Lücke finden, würde ich vorschlagen, sie nicht zu verwenden, es sei denn, sie wird von den Designern empfohlen oder zumindest sanktioniert.

Ich schlage vor, Sie suchen nach anderen Lösungen. Zum Beispiel:

• Müssen Sie wirklich die Objektinstanzen teilen? Wenn sie zustandslos sind, müssen Sie das möglicherweise nicht, und Sie können einfach eine Kopie des Kontexts in jeder App ausführen.
• Können Sie den Code, den Sie teilen möchten, in eine dritte WAR-Datei aufteilen, die einen Rest-Service verfügbar macht? Oder vielleicht könnte einer der bestehenden WARs als Service dienen.

Unser Team hatte genau die gleiche Anforderung - Spring Beans zwischen mehreren WARs in Tomcat zu teilen, und ehrlich gesagt sind Antworten wie "Mach das nicht" nicht hilfreich.

Die Anforderung ergibt sich aus der Tatsache, dass wir eine Multi-WAR-Anwendung auf Tomcat ausführen, und alle WARs benötigen Zugriff auf dasselbe RDBMS für persistente Informationen. Wir verwenden Spring und Hibernate, um auf die RDBMs zuzugreifen, und alle WARs teilen dasselbe Schema und können idealerweise denselben Transaktionsmanager für Hibernate SessionFactory und Spring verwenden.

Die Antwort, wie es gemacht wird, wurde hier gepostet:

StackOverflow: Teilen des ApplicationContext innerhalb der EAR

und zusammenfassend machen Sie folgendes in Ihrer web.xml:

wo beanRefContext.xml enthält:

Dies verwendet den Spring ContextSingletonBeanFactoryLocator Freigeben und Freigeben des übergeordneten Kontexts (in diesem Fall mit dem Namen "sharedContext"). Der freigegebene Kontext wird langsam geladen, wenn der erste WAR darauf verweist.

Alle Beans, auf die Sie im freigegebenen Kontext verweisen, müssen für alle WARs zugänglich sein, was bedeutet, dass sie nicht innerhalb einer bestimmten WAR aus WEB-INF / classes oder WEB-INF / lib geladen werden können. Sie müssen entweder mit einer EAR-Datei geteilt werden oder indem die Jars, die die Beans (und deren Abhängigkeiten) enthalten, in den freigegebenen Tomcat-Ordner "lib" ($ CATALINA_HOME / lib) gestellt werden, was unser Team getan hat.

Bitte warnen Sie davor, dass Sie, wenn Sie diesen Ansatz verwenden, die meisten Ihrer JARs im freigegebenen lib-Ordner und nicht in einzelnen Webapps haben. Für unser Projekt war dies sinnvoll, da die meisten Webapps dieselben Back-End-Services nutzen und darauf zugreifen.

Da die Hardcore-Tomcat-Entwickler sehr wahrscheinlich dagegen sind, viel Code in das Tomcat-Lib-Verzeichnis zu schreiben, werde ich nur einige Gründe aufzählen, warum die anderen vorgeschlagenen Antworten möglicherweise nicht funktionieren.

• Die Verwendung separater Anwendungskontexte für jede WAR würde bedeuten, mehrere Verbindungspools zur Datenbank zu haben, eine für jede WAR und separate Initialisierung der teuren Hibernate SessionFactory für jede WAR, was die Serverstartzeit und den Speicherverbrauch erhöht. Allgemeiner gesagt, lässt es nicht zu, dass der Status von gemeinsam genutzten Back-End-Diensten über Webapps geteilt wird, die auf demselben Tomcat laufen.
• Das Einfügen des Persistenz-Codes in eine separate WAR und die Verwendung von REST-Aufrufen, zumindest in unserem Fall, ist für Entwickler völlig unbequem und erhöht die Pfadlänge zur Datenbank im Vergleich zu direkten Aufrufen von Shared-Beans.

Es gibt vielleicht einen Weg, wenn Sie einen eingebetteten Jetty-Server starten und auf beide Web-Apps der Klasse zugreifen, in der Sie den Jetty-Server starten und konfigurieren.

Siehe:

Embedding Jetty

Müssen Sie den Kontext runtime freigeben oder möchten Sie einfach Bean-Definitionen für die beiden Anwendungen erneut verwenden?

Wenn es nur Letzteres ist, könnten Sie die gemeinsamen Spring-Kontext-XML-Dateien leicht in eine gemeinsame Abhängigkeit extrahieren und das JAR einfach zwischen den beiden Webapps wiederverwenden. Wenn Sie jedoch die Beans / Dienste in jeder Anwendung benötigen, um miteinander zu sprechen, benötigen Sie eine andere Option.

Sie könnten möglicherweise einen Kontext an JNDI binden, wenn es nicht existiert.

Der Preis dafür ist, dass jeder Webapp-Kontext irgendwie darauf achten muss, dass er nicht der primäre ist.

Außerdem müssen Sie sehr vorsichtig mit den Rennbedingungen umgehen, z. B.

• erste Webapp startet, erkennt, dass kein Kontext vorhanden ist
• erste Webanwendung beginnt mit dem Erstellen des Kontexts
• zweite Webanwendung startet, erkennt, dass kein Kontext vorhanden ist
• zweite Webanwendung beginnt mit dem Erstellen des Kontexts
• erste Webapp beendet den Kontext, bindet ihn
• Die zweite Webanwendung wird beendet, um den Kontext zu erstellen, bindet ihn
• herzlichen Glückwunsch, Sie haben alle Beans aus dem Kontext der ersten Webapp
verloren

Vereinbart mit @ Richard Smith, die akzeptierte Antwort war nicht hilfreich für mich. Während Richards Antwort hilfreich war, um mich in die richtige Richtung zu lenken, benutze ich Jetty, so dass ich EAR nicht benutzen kann. Ich benutzte den Server-Kontext, um ein Objekt zwischen Kriegen zu teilen - funktioniert sogar mit heiß (neu) bereitgestellten Webapps:

Ссылка

Wahrscheinlich eine Möglichkeit, dies auch für Tomcat anzupassen.