6 Replies Latest reply on Oct 13, 2004 11:09 PM by Tom Elrod

    Compatibility of serialized client invoker classes between J

    Simon Gunzenreiner Newbie

      I am wondering what the JBoss strategy is regarding (de)serialization of client proxy/intercepter etc. between different JBoss versions. Does one always have to use the same JBoss version (major?, minor?) or is there a concept of those serialized objects beeing portable between different JBoss versions? I am currently wondering whether we can use the JBoss RMI protocol between different JBoss versions, or we have to switch to SOAP. Is this topic treated differently now and in the upcoming JBoss remoting framework?

      Thanks for clarifications,
      Simon

        • 1. ClassLoader problem - Very Urgent
          Simon Gunzenreiner Newbie

          Hi,
          I am struck up with a problem with class loader. I was porting my product from WebLogic to JBoss. The scenario is like this :

          My product basically has a client and the server operating at remote machines. The Server provides an interface which is a remote object .
          This interface is implemented by the client .

          This callbackobject (implemented by the client) is passed as an input parameter to one of the methods of a Session Bean.
          When the client calls this method, the server throws...

          java.lang.ClassNotFoundException: x.y.sample

          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.net.URLClassLoader$1.run(URLClassLoa
          der.java:199)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.security.AccessController.doPrivileg
          ed(Native Method)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.net.URLClassLoader.findClass(URLClas
          sLoader.java:187)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.lang.ClassLoader.loadClass(ClassLoad
          er.java:289)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.lang.ClassLoader.loadClass(ClassLoad
          er.java:235)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.invocation.MarshalledValueInput
          Stream.resolveClass(MarshalledValueInputStream.java:85)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readNonProxyDes
          c(ObjectInputStream.java:1513)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readClassDesc(O
          bjectInputStream.java:1435)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readOrdinaryObj
          ect(ObjectInputStream.java:1626)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readObject0(Obj
          ectInputStream.java:1274)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readArray(Objec
          tInputStream.java:1603)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readObject0(Obj
          ectInputStream.java:1271)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.io.ObjectInputStream.readObject(Obje
          ctInputStream.java:324)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.invocation.MarshalledValue.get(
          MarshalledValue.java:78)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.invocation.MarshalledInvocation
          .getArguments(MarshalledInvocation.java:324)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.StatelessSessionContainer$C
          ontainerInterceptor.invoke(StatelessSessionContainer.java:629)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.resource.connectionmanager.Cach
          edConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.StatelessSessionIns
          tanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.AbstractTxIntercept
          or.invokeNext(AbstractTxInterceptor.java:84)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.TxInterceptorCMT.ru
          nWithTransactions(TxInterceptorCMT.java:243)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.TxInterceptorCMT.in
          voke(TxInterceptorCMT.java:104)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.SecurityInterceptor
          .invoke(SecurityInterceptor.java:117)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.LogInterceptor.invo
          ke(LogInterceptor.java:191)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.plugins.ProxyFactoryFinderI
          nterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.StatelessSessionContainer.i
          nternalInvoke(StatelessSessionContainer.java:322)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.ejb.Container.invoke(Container.
          java:674)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.reflect.GeneratedMethodAccessor40.inv
          oke(Unknown Source)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.reflect.DelegatingMethodAccessorImpl.
          invoke(DelegatingMethodAccessorImpl.java:25)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.lang.reflect.Method.invoke(Method.ja
          va:324)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.mx.capability.ReflectedMBeanDis
          patcher.invoke(ReflectedMBeanDispatcher.java:284)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.mx.server.MBeanServerImpl.invok
          e(MBeanServerImpl.java:549)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at org.jboss.invocation.jrmp.server.JRMPInvo
          ker.invoke(JRMPInvoker.java:359)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.reflect.GeneratedMethodAccessor42.inv
          oke(Unknown Source)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.reflect.DelegatingMethodAccessorImpl.
          invoke(DelegatingMethodAccessorImpl.java:25)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.lang.reflect.Method.invoke(Method.ja
          va:324)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.rmi.server.UnicastServerRef.dispatch(
          UnicastServerRef.java:261)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.rmi.transport.Transport$1.run(Transpo
          rt.java:148)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.security.AccessController.doPrivileg
          ed(Native Method)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.rmi.transport.Transport.serviceCall(T
          ransport.java:144)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.rmi.transport.tcp.TCPTransport.handle
          Messages(TCPTransport.java:460)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at sun.rmi.transport.tcp.TCPTransport$Connec
          tionHandler.run(TCPTransport.java:701)
          ERROR [RMI TCP Connection(1)-10.18.8.178] (?:?) - at java.lang.Thread.run(Thread.java:534)


          some where , i came to know that jboss uses the URLClassLoader concept and that it has a ClassLoaderRepository. I tried to invoke the classLoader, but it doesnot reach that part of the code. Once the call comes to the EJB Container , it throws exception.

          In some other documentation....this mbean is said to be put in jboss-service.xml file.


          <mbean code="org.jboss.remoting.transport.Connector"
          xmbean-dd="org/jboss/remoting/transport/Connector.xml"
          name="jboss.remoting:service=Connector,transport=Socket"
          display-name="Socket transport Connector">

          socket://localhost:8084



          <server-side>true</server-side>
          <client-side>true</client-side>


          org.jboss.mx.remoting.JMXSubsystemInvocationHandler






          But , i did not find the jar for this. So , i replaced the handler with
          org.jboss.aop.remoting.AOPRemotingInvocationHandler

          and checked. when server is started, It says handler not found ....hence quitting.

          Then, i have put the above tags . It shows no error but my purpose was not solved.

          In some other documentation , i found that .....
          these tags in jboss-web.xml should be changed.
          <class-loading>
          <loader-repository>
          weta:confluence=LoaderRepository
          <loader-repository-config>
          java2ParentDelegation=true
          </loader-repository-config>
          </loader-repository>
          </class-loading>

          I have changed true to false. But in vain, my problem is still not solved.
          I am using jboss-3.2.1 and j2skd1.4.2. Its working fine with WebLogic.


          Any help would be highly appreciated.

          • 2. Re: Compatibility of serialized client invoker classes betwe
            Tom Elrod Master

            Assume your question is related to EJB invocations? If so, when an EJB is deployed, the client proxy and interceptors are serialized and bound within JNDI. So when the client does the JNDI look up for the EJB, will pull the serializaed version the server bound. To deserialize within the client, will need jboss-client.jar on the classpath. These cient files do have serialVersionUID set and their signatures very rarely change. Thus, should be able to use a jboss-client.jar from 3.2.x with 4.0 server (or vise versa). I have not tested this myself, so you would need to test this to be sure. All this is for JBoss 3.2 and JBoss 4.0.

            In JBoss 5, this will likely change so that the client proxies that are downloaded will be able to dynamically load the classes they need from the server, so jboss-client.jar will not be required on the client classpath if configured to do so. Since I will be adding this, would certainly be interested in any feedback you might have as a user.

            • 3. Re: Compatibility of serialized client invoker classes betwe
              Simon Gunzenreiner Newbie

              sorry, didn't mean "portable", but to have the same serialVersionUID

              • 4. Re: Compatibility of serialized client invoker classes betwe
                Tom Elrod Master

                If just worried about client and server being interoperable between 3.2 versions, this should work. However, is possible that API of client proxy, interceptors which are used (i.e. transaction, security, etc.) or even invocation context may have changed between versions. If methods were removed in a later version or if method signature changed in any of the forementioned, you will get an error during runtime.

                Only way find out for sure is check CVS for such code changes between release or can just test. Testing is probably a better option, the code that is actually sent to the client will depend on the EJB interceptors specified for your ejb. For example, if using transactions, clustering and security, will have these three interceptors that get sent to the client.

                We do not test this currently.

                In the next major version of JBoss (was called 4.2, but now calling it 5.0) the dynamic classloading will probably not be RMI based so that can be used across multiple transport protocols.

                • 5. Re: Compatibility of serialized client invoker classes betwe
                  Simon Gunzenreiner Newbie

                  Sorry for the delay of my reply - just some last thoughts on this:

                  If the dynamic code loading is not RMI based, it should have means to plugin TLS socket factories to allow server authentication and secure transport.

                  The data which control dynamic classloading should be clearly defined so that many JBoss client library versions can use them to trigger dynamic class loading.

                  As long as classloading of client stubs is not decoupled from JBoss versions, it might be a good idea to swap out all classes that might appear in client stubs in separate jar files. Then one could at least load multiple versions of those classes, if you introduce something like class version numbers in Class names (e.g. org.jboss.proxy.SecurityInterceptor_1_0, like they did for the jdk omg libraries) - ugly, but might do the trick to allow a client to connect to multiple JBoss server versions.

                  What do you think?

                  • 6. Re: Compatibility of serialized client invoker classes betwe
                    Tom Elrod Master

                     

                    If the dynamic code loading is not RMI based, it should have means to plugin TLS socket factories to allow server authentication and secure transport.


                    This will be provided in future releases. Currently is just a coarse flag for turning classloading on or off in config (depending on if secured network or not) withint remoting framework.

                    The data which control dynamic classloading should be clearly defined so that many JBoss client library versions can use them to trigger dynamic class loading.


                    The goal is to make it this way. Will be up to each project lead as to if they think it makes sense to use it in their project.


                    As long as classloading of client stubs is not decoupled from JBoss versions, it might be a good idea to swap out all classes that might appear in client stubs in separate jar files. Then one could at least load multiple versions of those classes, if you introduce something like class version numbers in Class names (e.g. org.jboss.proxy.SecurityInterceptor_1_0, like they did for the jdk omg libraries) - ugly, but might do the trick to allow a client to connect to multiple JBoss server versions.


                    Not sure about this one. Will probably be working out versioning strategies in the near future, but don't know how they'll break out (i.e. by class, by module jar, etc.).