[JNDI] Holen einer EJB

[frischfisch]

Hallo,

ich Problem beim zuweisen einer EJB, die ich mir über JNDI hole:

return javax.rmi.PortableRemoteObject.narrow(objRef, narrowTo);

Das Problem ist Serverabhängig. Es funktioniert auf meinem Testsystem (JBoss), aber nicht auf einem anderen Server (auch JBoss). Dann wird mir an der Stelle eine ClassCastException geworfen. Soweit ich weiss, stehen die Informationen für den EJB-Container in den Deploy-Descriptoren, aber die sind identisch und werden ja mit der Applikation deployed.

Wo kann sonst der Fehler liegen?

Grüße, frischfisch.

 

[bronks]

Nur wegen der o.g. Zeile kann keine ClassCastException kommen. Das Problem muß irgenwo anders liegen.

Mehr Code ... mehr Infos ...

 

[frischfisch]

Hier noch etwas Kode:

      try {
         Object objRef = initialContext.lookup(jndiName);
       
         // only narrow if necessary
         if (java.rmi.Remote.class.isAssignableFrom(narrowTo))
            return javax.rmi.PortableRemoteObject.narrow(objRef, narrowTo);
         else
            return objRef;
      } finally {
         initialContext.close();
      }

Die Objekte werden über die DDs beim Deploy geladen, aber die Objektreferenzen sind scheinbar nicht gültig. Im Moment prüfe ich gerade die Konfigurationsdateien und bin über folgende XML-Stücke gestolpert (CallbyValue - einmal true im Test-Server/ falseper default):

   <mbean code="org.jboss.naming.NamingService"
      name="jboss:service=Naming"
      xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
      <!-- The call by value mode. true if all lookups are unmarshalled using
      the caller's TCL, false if in VM lookups return the value by reference.
      -->
      <attribute name="CallByValue">true</attribute>
   </mbean>

Mehr Antworten ... bitte

 

[frischfisch]

Selber gefunden:

The default JBoss setup forces call by value between class loader repositories.
So if app1 needs to call a bean in app2 and they both have loader repositories, it must do so with all the overhead of serialization.
In addition, the shared classes must be loaded outside of both class loader repositories.
So if app2 is calling methods on beans in app1, those classes must be put in a separate jar and deployed outside of both app1 and app2, otherwise you will get ClassCastExceptions.
This usually creates an undesirable packaging and deployment workflow.
To override the default call by value behavior [..].

Hab aber schon wieder das nächste Problem ...