-
1. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
Please post the entire exception stacktrace.
-
2. Re: Protocol change for EJB calls between a JBoss AS 4.2.1 i
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
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
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.