Ich versuche, meine EJBs mit einem eingebetteten EJB-Container zu testen. In der Produktion bin ich auf eine JTA-Datenquelle angewiesen, die auf dem Anwendungsserver konfiguriert ist. Während des Testens möchte ich jedoch eine Verbindung zu einer anderen DB (In-Memory-Derby) herstellen.
Das Problem ist, dass ich nicht sehen kann, wie der EJB-Container die JTA-Datenquelle, die in meiner Produktion persistence.xml (in src / main / resources / META-INF) definiert ist, mit einer Verbindung zu meinem In-Speicher überschreiben derby DB. Die JTA-Datenquelle ist in der Datei persistence.xml wie folgt definiert:
%Vor%Ich habe versucht, eine test persistence.xml-Datei zu erstellen (in src / test / resources / META-INF), die definiert:
%Vor%Dies ist jedoch problematisch, weil ich den EJB-Container für die Verwendung des zu testenden Moduls mit
angegeben habe %Vor%Der Container verwendet nur die Hauptdatei persistence.xml anstelle meines Tests.
Der einzige Weg, den ich sehen kann, damit dieser Ansatz funktioniert, ist die Verwendung des beschriebenen Ansatzes hier - um die Klassen für das getestete Modul an einen anderen Ort zu kopieren (zB target / ejb-testing-classes), dann kopiere die test persistence.xml Datei über die Geben Sie dann diesen neuen Speicherort für den EJB-Container an:
%Vor%Aber das scheint unnötig ungeschickt. Es könnte auch ein Problem in der Zukunft sein, wenn ich versuche, vorverpackte Module (dh Abhängigkeiten) im Container zu deployen, da ich die Jars vor dem Zusammenführen explodieren müsste.
Ich dachte, dass es weitere Eigenschaften geben könnte, die in den EJB-Container übertragen werden könnten, aber bisher kann ich nur Eigenschaften finden, die für openEJB oder websphere . Ich verwende eingebettete Glassfish, um meinen eingebetteten EJB-Container als Zielplattform bereitzustellen. (Ich habe jetzt die Glassfish-Eigenschaft gefunden - siehe Update # 1, unten)
Sicherlich hat jeder, der versucht hat, EJBs mit einem eingebetteten EJB-Container und einer anderen Datenquelle als der Produktions-DB zu testen, auf dieses Problem gestoßen. Sogar dieser Typ hat gerade an dieser Stelle aufgegeben und die Standard-DB verwendet, was für mich keine Option ist.
Jede Hilfe wäre sehr willkommen.
Update 1: Ich habe das Liste der Eigenschaften , die der Glassfish EJB-Container akzeptiert, und zunächst scheint es, dass ich die folgende Eigenschaft verwenden könnte
%Vor%um eine Datenquelle in einer domain.xml zu definieren und den Container darauf zu verweisen. Laut der Quellcode , diese Eigenschaft wird ignoriert, es sei denn, die Eigenschaft installation.root wird ebenfalls festgelegt. Dies würde bedeuten, dass eine bereits vorhandene Installation von Glassfish erforderlich ist nur um meine Tests zu starten. Dies würde die Portabilität meines Maven-Projekts inakzeptabel verringern. : (
Update 2: Ich habe ein JIRA-Problem für dieses Problem und empfahl, dass Eigenschaften für den Glassfish-EJB-Container eingeführt werden, der die Konfiguration einer JTA-Datenquelle ermöglicht.
Kann nicht mit eingebettetem Glassfish gemacht werden.
Wie in Update 1 erwähnt, müssen Sie, um den eingebetteten EJB-Container mit einer Datenquelle zu konfigurieren, Folgendes tun:
Also (dank Schritt 2) auf Wiedersehen, Portabilität. Aber das ist die "Lösung", die ich mitgehen muss, bis die Glassfish-Entwickler meine Anfrage zur Konfiguration von Datenquellen über eine Eigenschaft angehen (siehe JIRA-Link oben in der Frage).
Für meine Sachen funktioniert es ganz gut, wenn Sie den eingebetteten Container nicht direkt verwenden, sondern das Arquillian-Projekt dafür verwenden. Wenn ich den ShrinkWrap-Helfer benutze, kann ich sagen, dass ich einen Test persistence.xml (sowie andere Substitute) bestehen soll.
Dies zeigt ein ziemlich kurzes Beispiel: Ссылка
HTH, Timo
Tags und Links jpa java-ee ejb glassfish maven-glassfish-plugin