"JBAS014154: Failed to marshal EJB parameters" when invoking methods in remote EJB interfaces using EJB 2.1

[kayko_orrister]

We are porting an application that uses EJB 2.0 from JBoss 6.1.1 to JBoss 7.1.x; we understand that we have to use EJB 2.1 when moving to JBoss 7.1.x.

We have found that in this sample application, when we...

- make a call through the remote interface of one entity bean, which...

- returns a plain-old Java object that...

- contains a reference to a local interface of an entity bean...

we get the following exception:

java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:270)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:259)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:231)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:179)

       at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:43)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

       at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

       at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)

       at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)

       at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)

       at $Proxy14.returnPlainOldJavaObject(Unknown Source)

       at example.cannotmarshal.Controller.processRequest(Controller.java:57)

       at example.cannotmarshal.Controller.doGet(Controller.java:32)

       at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)

       at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)

       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)

       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)

       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)

       at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)

       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)

       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)

       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)

       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)

       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)

       at java.lang.Thread.run(Thread.java:662)

Caused by: java.io.NotSerializableException: example.cannotmarshal.EntityBeanA.EntityBeanALocal$$$view7

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:255)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)

       at org.jboss.marshalling.cloner.SerializingCloner.cloneFields(SerializingCloner.java:348)

       at org.jboss.marshalling.cloner.SerializingCloner.initSerializableClone(SerializingCloner.java:309)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:253)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:268)

       ... 28 more

Some peculiarities that we've noticed in conjunction with this exception:

- We have to make the plain-old Java object serializable ("implements java.lang.Serializable") or else we get a different "JBAS014154: Failed to marshal EJB parameters" exception complaining that it is not serializable.  This is something that we did not have to do on JBoss 6.1.1, Weblogic or Websphere, and appears to be a requirement of EJB 3.x rather than EJB 2.1.

- We've marked the plain-old Java object as serializable in order to proceed and gotten the above exception, which complains about a proxy not being serializable, which we don't have control over.

As it appears that it is imposing EJB 3.x restrictions on our remote interface calls, and also on this internal JBoss $$$view object as well, this looks like a bug, but I'd like to confirm.  We found a similar problem reported here that indicated that the best place to initially discuss the problem would be this forum:

https://issues.jboss.org/browse/AS7-6793 

We have built a small, distilled sample application to demonstrate this exception, and can submit it - please advise as to the preferred method of doing so in these forums.

The exception that is raised in our production application is similar, but it indicates that a different object should be marked serialiazble - ProxyInvocationHandler:

javax.servlet.ServletException: java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters

       [3 application-specific calls here]

       at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)

       at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)

       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)

       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)

       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)

       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489)

       at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)

       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)

       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

       at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:416)

       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)

       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)

       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)

       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)

       at java.lang.Thread.run(Thread.java:662)

Caused by: java.lang.RuntimeException: JBAS014154: Failed to marshal EJB parameters

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:270)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:259)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:231)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:179)

       at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:43)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

       at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

       at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

       at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)

       at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)

       at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)

       at $Proxy21.unlock(Unknown Source)

       [1 application-specific call here]

       ... 19 more

Caused by: java.io.NotSerializableException: org.jboss.as.ee.component.ProxyInvocationHandler

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:255)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)

       at org.jboss.marshalling.cloner.SerializingCloner.cloneFields(SerializingCloner.java:348)

       at org.jboss.marshalling.cloner.SerializingCloner.initSerializableClone(SerializingCloner.java:309)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:253)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)

       at org.jboss.marshalling.cloner.SerializingCloner.cloneFields(SerializingCloner.java:348)

       at org.jboss.marshalling.cloner.SerializingCloner.initSerializableClone(SerializingCloner.java:309)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:253)

       at org.jboss.marshalling.cloner.SerializingCloner.clone(SerializingCloner.java:134)

       at org.jboss.as.ejb3.remote.LocalEjbReceiver.clone(LocalEjbReceiver.java:268)

       ... 31 more

Due to the similarity, it looks like the problem in the sample may reveal something of the nature of the problem in the production application.  We've tried to get the same exception in the sample by approximating the conditions but we may need a little advice; in either case, the sample seems to demonstrate a potential bug in JBoss 7.1.x.

[sgilda]

Maybe this will help:  https://community.jboss.org/thread/196243

[kayko_orrister]

sgilda wrote:

Maybe this will help:  https://community.jboss.org/thread/196243

We have declared that the POJO that we return in the method call in the remote interface is serializable.  We do get an exception similar to the one discussed in that thread if we do not, and it complains that the POJO is not serializable.  This is unusual because it is a requirement of EJB 3.x, not 2.x, as discussed in that thread.

Nonetheless, after we declared that the POJO "implements Serializable", we get the exception in the original post, which you will see complains about an internal JBoss object that we do not have control over.

[kayko_orrister]

I am attaching my sample code to this message.

- You can build this project with Ant - the default target of the build.xml in the root directory will produce cannotmarshal.ear in the build/distribution directory.

- It uses the h2 database included with JBoss for convenience.

- The standalone-full.xml in the archive is configured to let the h2 database persist the tables on hard disk rather than memory.

- "tables.sql" is the SQL for setting up the tables for persisting the beans in the h2 database.

-  It sets up a servlet that can be accessed at http://localhost:8181/cannotmarshall -- press the button and it reproduces the exception, which will be written to stderr.

I think that should be it; I'll be looking out for questions and comments here.

[sfcoy]

kayko_orrister wrote:

  This is unusual because it is a requirement of EJB 3.x, not 2.x, as discussed in that thread.

This is not true.

It has always been a requirement that method parameters (and function results) satisfy the requirements for Java RMI, and a fundamental premise of this is that they be serializable.

From the EJB 2.0 spec §7.10.4:

{quote}The argument and return value types for a method must be legal types for RMI/IIOP if the method corresponds to a business method on the session bean’s remote interface{quote}

But is also true that many vendors implemented an optimisation for remote calls within the same VM in order to eliminate the serialisation cost of argument passing. But this is out of spec and typically predates the introduction of "Local" interfaces.

[kayko_orrister]

Ah, OK.  We hadn't seen this on other Java EE servers, and the referenced post refers to the EJB 3 specification, so I thought it was new to EJB 3.

As mentioned in the original post, I'm posting this as a preliminary stage to filing a bug report - would it be OK if I did that now?

[sfcoy]

It's not a bug. You cannot pass a local interface as a parameter (directly or indirectly) to a remote business method. It makes no sense.

The correct way to handle this situation is to

• add local home and interface classes for the EJB in question and use those instead of the remote varieties.

or

• change the local interface reference to a javax.ejb.Handle and reconstitute the EJB at the recipient.