WebSphere 5.1 EJB lookup in Network Deployment

[Paul Wong]

I am currently having a problem with looking up for EJBs deployed in my WebSphere network deployment environment. To lookup for the EJBs, I am using direct JNDI (i.e. without going thru EJB references).

I understand that in the network deployment we have to provide the prefix 'cell/clusters/<myclustername>/ejb/MyEJB'. Rather than having this prefix, is there are better way?

To solve this, a properties file can be introduced or there is a WebSphere API that can obtain the current Cell name. However, by having the properties file, every server would have to have a different properties file. This would not be a good practice and gives more work to the deployment team. And using the WebSphere API, the code cannot be reused in a standalone application (not in a J2EE container).

Any advice would be helpful. Thanks!

[Nicholas Cheung]

a properties file can be introduced or there is a WebSphere API that can obtain the current Cell name.

Currently, up to WSAD 5.1.1, it does not support a properties file based JNDI configuration. Your idea sounds reasonable, however, the JNDI names are expected to be changed rarely, just like DNS names, thus, this concept is not introduced yet.

As I am still waiting for the copy for WSAD 5.2, I am not sure whether this concept will be introduced, or maybe in WSAD 6.0.

Nick

[Paul Wong]

Just found another way around this which proved to work. Instead of having the PROVIDER_URL set to "iiop://localhost:2809", I have set it to "iiop://localhost:2809/cell/clusters/MyClusterName". After trying this out on WSAD's Universal Test Client, it seems to work.

Thanks

[Nicholas Cheung]

Instead of having the PROVIDER_URL set to "iiop://localhost:2809", I have set it to "iiop://localhost:2809/cell/clusters/MyClusterName".

This works because you have explicitly change the binding from "iiop://localhost:2809" to "iiop://localhost:2809/cell/clusters/MyClusterName". However, this seems fixed the URL. If you later wanna add one more access path, you still cannot avoid to code the prefix there.

Seems that you are now moving the prefix hardcoding from JNDI to provider url.

Nick