lookup auf entfernte SessionBean

[JavaKathi]

Hallo,

bisher war meine Strutsanwendung im selben AppServer (JBoss) deployed wie meine EJB Komponenten, auf die die Strutsanwendung zugreift. Funktionierte auch alles einwandfrei. Nun sollen die Webkomponenten auf einem anderen System laufen und übers Netzwerk auf die EJBs (genauer SessionBeans) zugreifen.

Beim Zugriff auf die SessionBean kommt es nun jedoch zu einer:

javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]

Wieso findet er plötzlich die Klasse nicht mehr?

lg
kathi

 

[Thomas Darimont]

Hallo!

Normalerweise brauchst du für einen (lokalen) LookUp inenrhalb eines Appservers nur mittels new InitialContext() einen InitialContext zu erzeugen und kannst dann per lookUp(...) die gewünschte Komponente finden.

Wenn du auf einen entfernten AppServer zugreifen willst musst du den InitialContext (für diesen LookUp) erst neu konfigurieren...
->

Hashtable environmentCont = new Hashtable();
        environmentCont.put("java.naming.factory.initial",
                "org.jnp.interfaces.NamingContextFactory");
        environmentCont.put("java.naming.factory.url.pkgs",
                "org.jboss.naming:org.jnp.interfaces");
        environmentCont.put("java.naming.provider.url", "jnp://theOtherAppServer:1099");

        InitialContext ctx = new InitialContext(environmentCont);

Dazu muss die WebAnwendung aber auch auf die passenden Jar's zugreiffen können.
(JBoss-Client bzw. / jbossall-client.jar). -> Kann es sein, dass eine Web-Anwendung innerhalb von Tomcat der wiederum in einem JBoss wohnt nicht direkt zugriff auf die "JBoss-Jar's" hat? Wenn dem so ist solltest du deinfach die zuvor genannten Jar's nach WEB-INF/lib deiner Webanwendungs befördern. Dann sollte es gehen.

Gruß Tom

 

[JavaKathi]

Hallo Tom,

der Zugriff auf die SessionBean funktioniert nun. Leider kommen neue Probleme und eine Reihe von Fragen:

1.) Der Benutzer wurde durch eine EntityBean (nur lokale Interfaces) realisiert. Ein entsprechendes Objekt lag nach dem Login in der Session. Innerhalb der Struts ActionKlassen habe ich dieses Objekt desöfteren aus der Session gelesen, um es einer Methode der SessionBean zu übergeben. Lokal war dies ja kein Problem. Dies funktioniert nun natürlich nicht mehr, da ich von ausserhalb nicht auf die EntityBean zugreifen kann. Hilft es der EntityBean entfernte Interfaces zu geben?

2.) Damit ich nicht in jeder ActionKlasse eine HashMap mit den Parametern füllen muss, wollte ich eine jndi.properties Datei anlegen. Findet der WebContainer diese automatusch, wenn sie im CLASSPATH liegt?

3.) Welchen Unterschied macht es in der lookup()-Methode den <jndi-name> oder den <ejb-ref-name> anzugeben?

4.) In der web.xml muss man die EJBs angeben, auf die innerhalb der Webanwendung zugegriffen werden soll. Dabei können nur EJBs mit entfernten Interfaces angegeben werden. Da in meinem Fall Struts und EJB in einem AppServer laufen, wären doch theoretisch auch für die SessionBeans nur lokale Interfaces möglich. Diese kann man jedoch nicht angeben?

lg
kathi

 

[Thomas Darimont]

Hallo!

1.) Der Benutzer wurde durch eine EntityBean (nur lokale Interfaces) realisiert. Ein entsprechendes Objekt lag nach dem Login in der Session. Innerhalb der Struts ActionKlassen habe ich dieses Objekt desöfteren aus der Session gelesen, um es einer Methode der SessionBean zu übergeben. Lokal war dies ja kein Problem. Dies funktioniert nun natürlich nicht mehr, da ich von ausserhalb nicht auf die EntityBean zugreifen kann. Hilft es der EntityBean entfernte Interfaces zu geben?

Du kannst für eine EntityBean mehrere Sichten pflegen (Local und Remote). D.h. es würde prinzipiell schon gehen jedoch wäre das nicht die beste Realisierung. In der EJB Entwicklung ist man eigentlich übereingekommen EntityBeans nur noch Lokal bereitzustellen und dann per SessionBean (Remote) von "außen" indirekt Zugriff zu diesem EntityBean zu gewähren. Für den Datentransport zwischen den beiden System würden sich dann wieder ValueObjects anbieten.

2.) Damit ich nicht in jeder ActionKlasse eine HashMap mit den Parametern füllen muss, wollte ich eine jndi.properties Datei anlegen. Findet der WebContainer diese automatusch, wenn sie im CLASSPATH liegt?

Die Datei würde dann zwar gefunden werden, jeodch wäre dadurch ja der InitialContext noch nicht "umkonfiguriert". -> Das musst du dann noch übernehmen.

[qoute]
3.) Welchen Unterschied macht es in der lookup()-Methode den <jndi-name> oder den <ejb-ref-name> anzugeben?
[/qoute]
Siehe:
http://docs.sun.com/source/816-5831-10/sessionejb/ejbref.html

4.) In der web.xml muss man die EJBs angeben, auf die innerhalb der Webanwendung zugegriffen werden soll. Dabei können nur EJBs mit entfernten Interfaces angegeben werden. Da in meinem Fall Struts und EJB in einem AppServer laufen, wären doch theoretisch auch für die SessionBeans nur lokale Interfaces möglich. Diese kann man jedoch nicht angeben?

Also angeben können tut man es auf jeden Fall in der web.xml (natürlich müssen die Einträge in der ejb-jar.xml und jboss-web.xml auch dazu passen):
Bsp:

 <ejb-local-ref>
      <ejb-ref-name>SomeBean</ejb-ref-name>
      <ejb-ref-type>Session</ejb-ref-type>
      <local-home>ejb.SomeBeanLocalHome</local-home>
      <local>ejb.SomeBeanLocal</local>
      <ejb-link>SomeBean</ejb-link>
   </ejb-local-ref>

Gruß Tom

 

[Thomas Darimont]

Hallo!

2.) Damit ich nicht in jeder ActionKlasse eine HashMap mit den Parametern füllen muss, wollte ich eine jndi.properties Datei anlegen. Findet der WebContainer diese automatusch, wenn sie im CLASSPATH liegt?


Die Datei würde dann zwar gefunden werden, jeodch wäre dadurch ja der InitialContext noch nicht "umkonfiguriert". -> Das musst du dann noch übernehmen.

Meine Antwort war natürlich zum Teil Käse. Wie man
http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/Context.html
entnehmen kann, kann man einen InitialContext doch durch eine im Classpath liegende jndi.properties Datei konfigurieren. Jedoch könnte es in deinem Szenario so sein, dass schon eine jndi.properties Datei im Classpath liegt welche den Default InitialContext des App-Servers Initialisiert.

Gruß Tom