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:
I get the following output:
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.
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 ]
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:
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
author and cow tipper
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.
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.
Joined: Oct 09, 2006
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 ]
Joined: Jan 07, 2008
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.
Joined: Oct 09, 2006
This is the technote where they explain why it happens: