Deployment von Local und Remote Interface

[Ralph Soika]

Hallo,

ich habe eine EJB entwickelt, welche sowohl das Local- als auch das Remote-Interface untnerstützt.
Im Deploymentdescriptor habe ich nun beide Interfaces angegeben. Laut Spezifikation von Sun ist dies zumindest nicht verboten.
Der Übliche Aufruf der EJB remote (über ...narrow(..)) oder lokal (über Type Casting) funktionert auch prima.
Nun habe ich einen ServiceLocator implementiert, welcher für das Caching die MetaDaten der EJB erfrägt:

Object ref = context.lookup(name);
EJBMetaData meta = ((EJBHome) ref).getEJBMetaData();

unter Verwendung von Websphere 6.0 kommt es nun genau hier teilweise zu folgender Exception:

java.rmi.NoSuchObjectException: object (class org.imixs.workflow.j2ee.ejb20.EJSRemoteStatelessDa tabaseHome_45f4ecd4) not exported
at com.ibm.rmi.javax.rmi.PortableRemoteObject.toStub( PortableRemoteObject.java:200)

Sobald ich die Deklaration des Local Interfaces aus dem Deploymentdescriptor entfehrne, funktioniert alles wie gewünscht.

Ich hatte nun aber auch schon die Situation das die EJB auch mit beiden Interfaces über den ServiceLocator erzeugt werden konnte.

Meine Frage ist nun:
Darf man eigentlich nur ein Interface Deployen? Oder woher weis eigentlich der Container, welches Objekt bei einem
context.lookup(name);

zurückzugeben ist?
Oder handelt es sich hier um einen Fehler innerhalb des vom WAS generierten Implementierungs Code?

Gruss
Ralph

[Oliver Ihns]

Hallo,

ich denke, dass Problem liegt darin begründet, dass der selbst geschriebene ServiceLocator über getEJBMetaData() sowohl auf das Home Interface einer entfernten EJB (EJBHome) als auch auf das Home Interface einer lokalen EJB (EJBLocalHome) zugreifen soll. DER PUNKT IST:

- der Zugriff über getEJBMetaData() funktioniert NICHT auf ein EJBLocalHome-Interface (also eine lokale EJB)!

- Die Methode getEJBMetaData() ist ausschließlich im EJBHome-Interface (dem Remote-Interface einer entfernt zugreifbaren EJB) definiert und gestattet somit auch nur den Zugriff auf eine Remote-EJB!

D.h. der Zugriff mit getEJBMetaData() auf das Local Interface muss zwangsläufig zu einer Exception führen. Hilft diese Information erst einmal?

Gruß,
Oliver Ihn

[rsoika]

Hallo,

ja das habe ich so verstanden. Deswegen habe ich in meinen ServiceLocator auch eine eigene Methode für das auffinden von lokalen EJBs implementiert (getLocalHome).

Daher nochmal zu meiner Frage:
Wenn ich nun (wissend das ich ein Remote Objekt benötige) die Methode: getHome("java:comp/env/ejb/MyEJB") aufrufe, woher weis dann eigentlich der EJB Container was für ein Objekt er mir bei :

Object ref = context.lookup(name);

zurückliefern soll?

Im Deploymentdescriptor habe ich ja hier nur eine EJB mit dem Namen "MyEJB" deployed und dort einfach beide Interfaces deklariert.

.....
<ejb-name>MyEJB</ejb-name>
<home>org.imixs.MyEJBHome</home>
<remote>org.imixs.MyEJB</remote>
<local-home>org.imixs.MyEJBLocalHome</local-home>
<local>org.imixs.MyEJBLocal</local>
.....

ist das Falsch? Oder ist es gar verboten beide Interfaces gleichzeitig zu deklarieren?
Mitlerweile habe ich das Problem so gelöst, dass ich einfach nochmal die selbe EJB mit dem Namen "MyLocalEJB" deploye.

Gruss
Ralp

[Oliver Ihns]

Hallo,

also grundlegend ist es so, dass es auch laut Spezifikation zulässig ist, beide Interfaces (remote und local) gleichzeitig im Deployment-Deskriptor anzugeben; und auch funktioniert ;-)

Der Punkt ist, dass der EJB-Container natürlich irgendwie das Mapping zum korrekten Interface (local oder remote) hinbekommen muss. Realisiert wird dies dadurch, dass im herstellerspezifischen Deployment-Deskriptor (also nicht ejb-jar.xml) jeweils ein JNDI-Name für das remote interface und ein JNDI-Name für das local interface angegeben werden muss.

Letztlich hast Du (ich hoffe, dass Duzen geht in Ordnung;-) genau das mit deiner handgestrickten VAriante des extra Deployens unter einem anderen Namen auch getan. Es geht aber auch einfacher, in dem man entsprechend innerhalb eines Deployment Descriptors für die EJB diese JNDI-Angaben hinterlegt.

Gruss
Olive