# [JNDI] Holen einer EJB



## frischfisch (20. Feb 2007)

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 (20. Feb 2007)

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

Mehr Code ... mehr Infos ...


----------



## frischfisch (20. Feb 2007)

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 (22. Feb 2007)

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.
> ...


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


----------

