9 Replies Latest reply on Sep 19, 2007 8:59 AM by jhalliday

    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.

        • 1. Re: IIOP stub compiler design problem
          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



          • 2. Re: IIOP stub compiler design problem
            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.

            • 3. Re: IIOP stub compiler design problem

              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

              • 5. Re: IIOP stub compiler design problem
                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.

                • 6. Re: IIOP stub compiler design problem
                  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?

                  • 7. Re: IIOP stub compiler design problem

                     

                    "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).

                    • 8. Re: IIOP stub compiler design problem

                       

                      "adrian@jboss.org" wrote:
                      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????

                      • 9. Re: IIOP stub compiler design problem
                        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.