EJB und Abhängigkeiten zu anderen EAR/EJB

[TheDarkRose]

Sagen wir mal einfach ich habe in einem Application Server eine eigenständig laufende EAR deployed, welche EJB und WAR Projekte enthält. Nun möchte ich so eine Art Add-On entwickeln, welche aber gewisse Abhängigkeiten (natürlich nur auf Interfaces) zu dem schon bereits vorhanden EAR hat. Kann ich dieses Add-On einfach als einzelnen EJB .jar parallel deployen und mir wie gewohnt per @EJB aus dem anderen Projekt alles injecten lassen, oder muss ich das Add-On .jar zusätzlich in die ursprüngliche .ear mitpacken und redeployen?

 

[mavinatic]

Ich bin mir nicht sicher, aber es ist im JBoss egal, denn du kannst wenn du mal deine deployten Jars betrachtest im JNDI-View, theoretisch zwar sehen in welchen Jar sie sind, aber unabhängig davon werden die EJB's einzelnt angezeigt, deswegen denke ich mal kannst du unabhängig auf die einzelenen EJBs zurückgreifen.

 

[TheDarkRose]

Gut so, werde ich mal, sobald ich zeit habe ausprobieren.

 

[Sym]

Ich bin mir nicht sicher, aber es ist im JBoss egal, denn du kannst wenn du mal deine deployten Jars betrachtest im JNDI-View, theoretisch zwar sehen in welchen Jar sie sind, aber unabhängig davon werden die EJB's einzelnt angezeigt, deswegen denke ich mal kannst du unabhängig auf die einzelenen EJBs zurückgreifen.

Ich glaube, das hängt aber stark von dem EE-Server ab, oder? Der JBoss verhält sich da ja anders als z.B. der Glassfish, soweit ich weiß.

Ich glaube, im Sinne von EE müsstest Du über Remote EJBs Zugriff erhalten.

 

[TheDarkRose]

Unterschied zwischen JBoss und Glassfish habe ich bis jetzt nur folgendes festgestellt:
- Thema JAAS: JBoss hält sich da ziemlich an den Standard, aber Glassfish fällt da total aus der Reihe und ich hab JAAS nicht wirklich zum laufen gebracht.
- Thema JNDI-Names: Glassfish supportet den java:global Namen, während Jboss eigene JNDI-Namen für die EJB kreiert. Ob sich das beim JBoss AS 7 geändert hat, habe ich noch nicht evaluiert.
- Thema Remote Application Client: JBoss stellt eine einzelne JAR (welche auf Sub-JAR's) verweißt bereit für den Application Client. Glassfish bietet hauptsächlich nur die Webstart Methode, oder man muss auf jeden Rechner Glassfish installieren und dann kann man dein application-launcher verwenden.


Back to topic:
@Remote Interfaces braucht man eigentlich nur für entfernte Aufrufe, wie Application Client zu EJB, oder EJB zu EJB, wenn diese auf unterschiedlichen Servern laufen.
Da aber bei mir beides in der selben JBoss Instanz deployed wird, sollte eigentlich ein @Local Interface auch funktionieren. Da in diesem Fall ja alles lokal im Server abläuft. Wie gesagt, muss ich noch ausprobieren.

 

[FArt]

Bis einschließlich JBoss 6 funktioniert das auf jeden Fall. Die @EJB Annotation hält halt noch ein paar Fallstricke bereit.. am besten man verwendet dann zum Injizieren den EJB Namen, den gemappten Namen oder den JNDI Namen. (Ausnahme, wenn eigene Loaderrepositories defniert werden, da muss man noch etwas mehr Hirnschmalz bzgl. Assembly der Komponenten reinstecken).

Ab JBoss 7 muss man beachten, dass jedes Modul per Default erst mal isoliert gegenüber anderen Modulen ist. Abhängigkeiten müssen explizit definiert werden.
Ohne es probiert zu haben, müsste aber auch hier ohne spezielle Abhängigkeit eine Injection funktionieren, wenn man z.B. den JNDI Namen verwendet und Remoteinterfaces. Von der Theorie her würde ich aber schätzen, dass man nun beim Assembly aufpassen muss: das Remoteinterface der Beans müsste dann eigentlich in beiden Module vorhanden sein.

Vermutlich reicht aber auch schon eine Injection, um die Abhängigkeit zu definieren.... ?!?

 

[Sym]

Back to topic:
@Remote Interfaces braucht man eigentlich nur für entfernte Aufrufe, wie Application Client zu EJB, oder EJB zu EJB, wenn diese auf unterschiedlichen Servern laufen.
Da aber bei mir beides in der selben JBoss Instanz deployed wird, sollte eigentlich ein @Local Interface auch funktionieren. Da in diesem Fall ja alles lokal im Server abläuft. Wie gesagt, muss ich noch ausprobieren.

Funktionieren tut es. Aber das "Addon" soll ja unabhängig vom EAR deployed werden und ist nur "zufällig" auf demselben EE Server. Aus architektonischer Sicht würde ich das nicht über Local-EJBs lösen. Ist aber sicher Geschmacksache und schneller sind localEJBs natürlich.

 

[TheDarkRose]

Ok, aus architecktonischer Sicht hast du recht. Aber wie weiß der andere EE Server, wo er das remote EJB zu finden hat?

 

[FArt]

Ok, aus architecktonischer Sicht hast du recht. Aber wie weiß der andere EE Server, wo er das remote EJB zu finden hat?

Entweder selber machen (Lookup) oder über Clustering und HA-JNDI.