4 Replies Latest reply on Feb 25, 2009 3:58 PM by Alex Taylor

    Protocol change for EJB calls between a JBoss AS 4.2.1 insta

    Alex Taylor Newbie

      Hi,

      I'm in the situation where I need to make a stateless session bean (EJB3) call between a JBoss AS 4.2.1 server and a JBoss 5.0.0 server (Stateless bean hosted on the 5.0.0 instance)

      If I don't include the JBoss 5.0.0 client jars in my 4.2.1 instance lib directory, I get a javax.naming.Reference (ClassCastException) error. I have checked the JNDI path, it's fine, and a standalone client with jbossall-client works fine.

      If I include two jars (jboss-ejb3-common-client.jar and jboss-ejb3-proxy-client.jar) on the 4.2.1 side, the javax.naming.Reference issue is replaced with: (on the client) :

      java.lang.NoSuchMethodError: xxx.xxx.xxxxx.core.bean.session.base.XxxxxxWorkflowServices.print()V

      (Print being the test bean call) - note the 'V' at the end of the line.

      And on the server:

      java.io.EOFException
      at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:691)
      at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
      at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)


      Has there been a protocol change in intercomms between the two versions of Jboss? Is there any way to make a stateless session bean call between 4.2.1 and 5.0.0?

      Any help would be greatly appreciated.

      Alex.

        • 1. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
          jaikiran pai Master

          Please post the entire exception stacktrace.

          • 2. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
            Alex Taylor Newbie

            This is the entire stacktrace - on the server side, there's just those three lines, and on the client (caller) side - it's just a stack through my code, then jboss. On the client, before it hits my code, it's:

            at sun.reflect.GeneratedMethodAccessor428.invoke(Unknown Source)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:585)
            at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
            at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495)
            at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
            at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116)
            at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
            at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
            at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
            at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
            at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)
            at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
            at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
            at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)
            at org.jboss.ejb.Container.invoke(Container.java:954)
            at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)
            at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)
            at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)
            at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:905)
            at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
            at org.jboss.mq.SpySession.run(SpySession.java:323)
            at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
            at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
            at java.lang.Thread.run(Thread.java:595)


            So nothing really exciting there..

            • 3. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
              jaikiran pai Master

              Unfortunately, the logs that you posted in your first post doesn't tell much about what wrong. Infact, i don't see any jboss specific files in the log which show a version conflict.

              If I don't include the JBoss 5.0.0 client jars in my 4.2.1 instance lib directory, I get a javax.naming.Reference (ClassCastException) error. I have checked the JNDI path, it's fine, and a standalone client with jbossall-client works fine.


              Please post this piece of exception stacktrace.

              While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

              • 4. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
                Alex Taylor Newbie

                Hi,

                Thanks for your help so far. I guess this is quite a hard problem to express and diagnose. The odd part is:

                java.lang.NoSuchMethodError: xxx.xxx.xxxxx.core.bean.session.base.XxxxxxWorkflowServices.print()V
                


                I call outward from Jboss-4.2 to the Jboss-5.0.0 hosted session bean, get this stack trace on the server side (and only this):

                java.io.EOFException
                at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:691)
                at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
                at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
                


                .. and on the client side, I get *only* the NoSuchMethodError. The rest of the client side stacktrace is just the path it took my initial bean call (i.e. largely uninteresting.

                The strange part is that the method it 'claims' I called - i.e. '.print()V' does not exist, and is not what I called - i.e. I call '.print()' on the bean, and it is callable via a standalone client with the jboss-5.0.0 jbossall-client.jar. Obviously, 'print()V' makes no sense at all.

                It appears to be some kind of conflict between jboss-4.2 EJB3 client libs, and the jboss-5.0.0 ones. Should it be possible at all to call a jboss-5.0.0 hosted EJB3 session bean from a jboss-4.2 container? Should I need the jboss-5 ejb3 client libraries, or should the 4.2 ones suffice?

                Thanks for your help,

                Alex.