InitialContext

Can you please tell me what I'm doing wrong?

This is a session bean trying to connect to a remote session bean.
The following code works great as a standalone app but blows up in the container.

Thanks, it's been a long day

When you are in the container, there shouldn't be any properties, and you should try to do a local lookup, rather than remote. That is not saying that you might have to do a Remote. It all depends on which class loader has the class and are you in the same class loader.

So when in the container, use

InitialContext context = new InitialContext();

Mark

Be aware that providing properties for a 'remote' JNDI lookup can screw up the container because some app server (BEA WebLogic) is introducing its own security manager when you use its client library.
AFAIK there is no need to make any remote JNDI lookup because J2EE provides you with a possibility to use CORBA name to access a remote EJB from within an container (search on the Internet for 'corbaname' I think).

-Andy

Kris, are you still working on the stuff were you are running in Sun's appserver but are trying to get to a different WebLogic instance (hence the need for the remote lookup)?

Thanks for the help guys

Yes this is a Session Bean running on Sun App Server trying to connect to a Session Bean on Web Logic. I can make the connection with my plain jave app but not in the container

I'll look into what you guys said

Thanks

Kris

Just to make sure you have all the info here is the exception the code throws

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.RemoteException
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:161)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:67)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:142)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(Unknown Source)
at whois._Whois_DynamicStub.search(_Whois_DynamicStub.java)
at WhoisClient.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:237)
at com.sun.enterprise.appclient.Main.<init>(Main.java:430)
at com.sun.enterprise.appclient.Main.main(Main.java:99)
Caused by: java.rmi.RemoteException
at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.java:199)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:853)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:160)
at $Proxy40.search(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:123)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatche
rImpl.java:648)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.jav
a:192)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:17
09)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1569)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:951)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:721)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:469
)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1258)

at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:409)

I believe I am making progress
Thanks Andreas for telling me about "corbaname".

I have now added to the sun-ejbjar.xml (It has no spaces)

Now in the EJB I call

Now I get the following message
No object bound to name java:comp/env/LookupAgent

This is driving me MAD!

I'd suggest splitting this into smaller steps. Trying to get from a bean in one container to a bean in another vendor's container requires a lot of moving parts.

I'd suggest binding something trivial to the Weblogic JNDI tree, like a simple string value. You could use a really simple servlet to bind the value ("hello world", for instance), hit the URL for that servlet to make sure it is loaded, and then the bound value will be in place.

Then, in the Sun container, use typical JNDI lookup code (specifying the JNDI properties, getting a context, etc.) in your EJB to try and get to that string in Weblogic's global JNDI tree. Don't use deployment descriptor bindings (so no comp:java/env/...), just do the access in the most direct way possible.

If you *can't* make that "hello world" scenario work, Corba, RMI-IIOP, etc. just aren't relevant for you yet. Something more fundamental would be going wrong with getting your JNDI provider to work, like a squabble between the Sun libraries and the Weblogic libraries. In your posting in the other thread you mentioned you dumped in everything into your app on the Sun side, not experimented with finding the minimal Weblogic client library set. If that is still the case, it is possible some library contention is at issue. Definitely there is library content in some of the Weblogic libraries for which it is a J2EE spec violation to try and include them in any deployed application.

If you can make the canonical example work, then it should be a simpler matter of changing one piece of the example at a time to migrate from "hello world" to bean-talking-to-bean. At least then if something breaks in the transition, you'll have a pretty good idea what kinds of issues could or couldn't be in play based on what was working last and what specifically you just changed.
[ March 15, 2006: Message edited by: Reid M. Pinchback ]

Thanks for the help mate, I appreciate it!

Only floor in the plan is I have no access to the Web Logic server. All I have it the JNDI name, hostname and port.

I think I am making leg way with the corbaname:iiop
I'm getting:
javax.naming.CommunicationException: Cannot connect to ORB [Root exception is org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe]

SUN minor code: 208 - literally means "CONNECTION ABORT", which generally means the connection has been dropped.

Just trying to work out who dropped the connection.

Thanks again

Kris

And also note, that in my mind I thought you were within the same container. Till Andreas told me otherwise.

Mark

I'm now getting a different error. Which I think is closer to the solution

My new code is:

This throws

Could not communicate to server because: java.io.FileNotFoundException: http://hostname.com:1113/getior

My question is what file is not found? weblogic.jndi.WLInitialContextFactory?

The above code works perfect outside the container using the T3 protocol instead of IIOP

Any healp would be extremely appreciated

Thanks

Kris

Hi Kris,

The T3 protocol is proprietary to BEA Weblogic and this needs to be used while using its JNDI for lookup.

I was under the impression that for container to container communication it has to be CORBA compliant and T3 isn't.

That is why the code works using the T3 protocol outside the container but doesn't work inside.

I could be speaking rubbish, can anyone confirm?