JNDI lookup across different WebSphere6 profiles, impossible?

[Jaime Garc�a]

Hi everybody,

I am experiencing some trouble trying to complete what looked like a very simple task, but got me stuck for days :'(

The thing is:
I have one WebSphere 6 base installation, with two profiles created.
Profile1: (myHostNode01Cell/nodes/myHostNode01/servers/server1; name server port: 2809)
Profile2: (myHostNode02Cell/nodes/myHostNode02/servers/server1; name server port: 2810)

I have an EJB deployed on Profile1's server (myHostCell01/nodes/myHostNode01/servers/server1/ejb/myEjb), and when I try to look it up from Profile2's server, using the following code:

Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "iiop://myHost:2809");
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
InitialContext ic = new InitialContext(env);
System.out.println("Context starting at: " + ic.getNameInNamespace()); // Pay attention to this output
Object o = ic.lookup("ejb/myEJB");
System.out.println("Object bound to ejb/myEJB: " + o);

I get the following output:

Context starting at: myHostNode02Cell/nodes/myHostNode02/servers/server1
 
javax.naming.NameNotFoundException: Context: myHostNode02Cell/nodes/myHostNode02/servers/server1, name: ejb/myEJB: First component in name myEJB not found.  Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL  :o  mg.org/CosNaming/NamingContext/NotFound:1.0
at com.ibm.ws.naming.ipcos.WsnOptimizedNamingImpl.do_resolve_complete_info(WsnOptimizedNamingImpl.java:543)
at com.ibm.ws.naming.cosbase.WsnOptimizedNamingImplBase.resolve_complete_info(WsnOptimizedNamingImplBase.java:2213)
at com.ibm.WsnOptimizedNaming._NamingContextStub.resolve_complete_info(Unknown Source)
at com.ibm.ws.naming.jndicos.CNContextImpl.cosResolve(CNContextImpl.java:4043)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1746)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1707)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1412)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1290)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:145)
at javax.naming.InitialContext.lookup(InitialContext.java:361)
at com.ibm._jsp._TestCase.getMyEJB(_TestCase.java:107)
at com.ibm._jsp._TestCase._jspService(_TestCase.java:156)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:91)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1572)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1521)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java(Compiled Code))
at co.com.proteccion.mua.servlet.filter.ValidarSesionFilter.doFilter(ValidarSesionFilter.java:98)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:142)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java(Compiled Code))
at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java(Compiled Code))
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:759)
at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:121)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionServletWrapper.handleRequest(JSPExtensionServletWrapper.java:204)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:89)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1924)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:89)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:472)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:411)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:288)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:207)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:109)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java(Compiled Code))
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java(Compiled Code))
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java(Compiled Code))
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java(Compiled Code))
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))
 

It seems that I cannot instanciate an InitialContext from one profile's server to another.

I have tried corbaname and corbaloc format for the provider url. I have also tried using ejb-ref, configured bindings (CORBA), with no success.


When I run this code from another server (in another machine), it just works fine.

Context starting at: myHostNode01Cell/nodes/myHostNode01/servers/server1
Object bound to ejb/myEJB: IOR:0000000000000037524d493a636f2e636f6d2e70726f74656363696f6e2e6c6f672e656a622e4c6f67486f6d653a30303030303030303030303030303030000000000001(...)

Do you guys know if it is posible to access to a was6 profile's server JNDI namespace from another profile?

Thanks in advance!

[ October 09, 2006: Message edited by: Jaime Garc�a ]
[ October 09, 2006: Message edited by: Jaime Garc�a ]

[Jeanne Boyarsky]

Moving to our IBM forum since it something WebSphere experts would know.

[Cameron Wallace McKenzie]

I think the issue you're hitting on has to do with the federated namespace.

You don't need to connect to the other servers JNDI context. You can connect to the context on the local server. However, you need to be able to locate the EJB.

"In this case, you could use the architecture dependent JNDI name,

Imagine an administrative cell named �soccer� and a node in that administrative cell named �worldcup� To find an EJB named �ejb/com/pulpjava/session/Timer� that is running on an application server named germany01 on the worldcup node, the topology dependent JNDI name used to perform the lookup would look like this:

cell/nodes/worldcup/servers/germany01/ejb/com/pulpjava/session/Timer

Notice how the JNDI name includes the name of the node, the server, and the EJB. The JNDI name is dependent upon the topology of the WebSphere environment."


Of course, this assumes that the two profiles are part of the same administrative domain. They are, right?

You can read more about JNDI naming with WebSphere here:

http://www.technicalfacilitation.com/get.php?link=naming

Cheers!

-Cameron McKenzie

[Jaime Garc�a]

Hi Cameron,

Unfortunately, the two profiles don't belong to an administrative domain, as they are part of a WAS 6 base installation (not ND), therefore, each standalone application server is located in a different cell. Of course, if the two profiles were federated into a deployment manager cell, I would not be facing this tricky problem, but installing ND is not feasible right now.

Thanks for your answer!

[Cameron Wallace McKenzie]

Sorry for making the assumption that this was all part of a common administrative domain. We know what they say about assumptions.

I'm afraid you're going to have to treat them as two totally separate name servers.

I guess you're doing that, right?

My fear might be that your'e connecting to the wrong JNDI port. Do a netstat -a and see which ports the various namespaces are running on.

After that, you might want to do a dumpnamespace, which is a WebSphere utility. You can configure it to connect to the appropriate port. Make sure the JNDI server you are connecting to ACTUALLY HAS the object you are looking for bound to it.

You've got so many different ports running JNDI here, it could definitely get confusing. But is should also be doable. I think I may try it in my local test environment.

Cheers!

-Cameron McKenzie

[Anders Lunden]

Hi!
I realize that this is a longshot since the thread is quite old, but anyway. Jaimito, did you ever get to the bottom of these cross-profile EJB-calls? I'm experiencing the same problems when trying to call an EJB deployed on WAS 6.0 from web module deployed on WAS 6.1.

[Jaime Garc�a]

Hi Anders, I could finally solved my very particular problem by the following workaround:

Turns out that because of some weird bug in websphere, you can't issue JNDI lookups across equally named servers of profiles that belong to the same installation; a simple renaming of one of the servers was enough to get the application working (renaming provided by some useful wsadmin scripts downloaded from IBM's site). Right now I don't have the link to the bug description page, but I'll post it once I can retrieve it.

Anyway, your problem seems to be very different though. Could you post some stacktrace or code so we can help you with yours?
[ January 07, 2008: Message edited by: Jaime Garc�a ]

[Anders Lunden]

Hi Jaime,
Thanks for the confirmation. I got to that conclusion myself and posted my findings at IBM developerWorks. I assumed that this was a bug, but I couldn't find a bug report of it. It would be interesting to see if you find that URL.

Thanks!

[Jaime Garc�a]

This is the technote where they explain why it happens:

http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&dc=DB520&dc=D600&dc=DB530&dc=D700&dc=DB500&dc=DB540&dc=DB510&dc=DB550&q1=%22objectName%22+not+found&uid=swg21201631&loc=en_US&cs=utf-8&lang=en

The problem is not really considered as a bug, so no fixes for this other than satisfy this undocumented uniqueness restriction.