IIOP stub compiler design problem

[jhalliday]

Francisco or anyone else who had a hand in the IIOP framework for JBossAS 4.0.5:

I'm deploying an EJB (v2 vintage) into JBossAS 4.0.5 and trying to access it from another EJB, using RMI/IIOP. It works fine until I need transaction propagation on the call. I've plugged in ArjunaJTS, which registers interceptors with the AS's default ORB instance to handle the transaction context propagation. On most calls these work fine.

However, for calls to the EJB, a different ORB is used and it does not have the interceptors registered on it. As far as I can tell, the client stub for the EJB is being built on the fly by the IIOPStubCompiler. How does it determine the ORB to use and how do I force it to use the same one as the rest of AS i.e. the one with the interceptors configured on it?

Thanks

Jonathan.

[reverbel]

Yes, the client stub for the EJB is being built on the fly by the IIOPStubCompiler. However, that stub should also use the default ORB instance in the AS.

Are you using the JNDI context factory that avoids the creation of other ORB instances? If your jndi.properties file (the one in the conf dir of the AS) has a line

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

replace that line with

java.naming.factory.initial=org.jboss.iiop.naming.ORBInitialContextFactory

You can disable the usage of dynamically generated stubs by putting rmic-generated stubs in the client classpath. This should not be necessary, though. Everything is supposed to work with the dynamic IIOP stubs.

Regards,

Francisco

[jhalliday]

> Are you using the JNDI context factory that avoids the creation of other ORB instances?

No I'm using com.sun.jndi.cosnaming.CNCtxFactory because I want naming over CORBA and I was under the impression that ORBInitialContextFactory did naming over JRMP.

[adrian.brock]

If you are using a corbaname or corbaloc url, the initial context is only relevant
for determining the ORB to use. JRMP is not used for those urls,
it should be using RMI/IIOP via the ORB.

If you don't set the ORB in the initial context explicitly, the JDK will create its own ORB
(on every lookup!) which you haven't configured with your portable interceptor. :-)

See:
http://java.sun.com/j2se/1.3/docs/guide/jndi/jndi-cos.html#ORB

[adrian.brock]

Also:
http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/Server_Configuration_Guide/The_Naming_InitialContext_Factories-The_ORBInitialContextFactory.html

[jhalliday]

Thanks Adrian. It's actually for 4.0 not 4.2 but I don't suppose much has changed in this area. I'll give it a try over the weekend.

[jhalliday]

Adrian -

What's the correct technique where a client application is needing to use dynamically generated stubs? Presumably the compilation occurs on the server and the stub is sent down to the client. Does the generated code do runtime lookup of the ORB to use in the client JVM? How do I interfere with that process, since ORBInitialContextFactory is not present on the client? Or do I need to add it to the client classpath, even though it's part of the /server/lib not /client/lib It seems like if I can do a ORBInitialContextFactory.setORB(myORB); in the client and the dynamically loaded stubs will respect it then that should work?

[adrian.brock]

"jhalliday" wrote:
Adrian -
What's the correct technique where a client application is needing to use dynamically generated stubs? Presumably the compilation occurs on the server and the stub is sent down to the client. Does the generated code do runtime lookup of the ORB to use in the client JVM? How do I interfere with that process, since ORBInitialContextFactory is not present on the client? Or do I need to add it to the client classpath, even though it's part of the /server/lib not /client/lib It seems like if I can do a ORBInitialContextFactory.setORB(myORB); in the client and the dynamically loaded stubs will respect it then that should work?

The ORBInitialContextFactory should be automatically setup by the appclient environment.
If you are outside an appclient then you need to do it yourself.

Other alternatives include:
1) Setting the ORB in the environment yourself (after the initial context
is constructed)
2) Configuring the ORBInitialContextFactory yourself
3) Writing your own ICF
4) Let CosNaming create an ORB for every request, but override all
the system properties to make it use JacORB
when it creates a new one (see the testsuite for details).

[adrian.brock]

Does the generated code do runtime lookup of the ORB to use in the client JVM?

It is handled by the ORB itself.

How do I interfere with that process.

This hack would involve something like casting the object to a corba ObjectImpl
and setting the delegate manually. Not sure how that would work if you are
changing ORBs????

[jhalliday]

When I'm running outside the app server

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
p.put("java.naming.corba.orb", myORB.orb());
p.put(Context.PROVIDER_URL, "corbaloc::localhost:3528/JBoss/Naming/root");

seems to be the way to go since ORBInitialContextFactory is not available. Inside the app server ORBInitialContextFactory does the right thing.

Now if we can just sort out the TxServerInterceptor hardcoding, pluggable JTS integration may actually work.