Tomaz Cerar created WFLY-8907: --------------------------------- Summary: ClassCastException due to wrong class loader after remote EJB invocation inside the same JVM Key: WFLY-8907 URL: https://issues.jboss.org/browse/WFLY-8907 Project: WildFly Issue Type: Bug Components: EJB, Remoting Reporter: Tomaz Cerar Assignee: David Lloyd Attachments: projects.zip, wildfly.patch.txt reported on github https://github.com/wildfly/wildfly/issues/9990 by https://github.com/strohmattenverleger Hello, I think I've discovered a bug in WildFly 10.1 regarding remote EJB invocations inside the same JVM. When the caller uses an interface for a remote invocation which is part of a JBoss module instead of the calling Java EE module, WildFly tries to clone the entire return value object graph using the interface's JBoss module class loader instead of the Java EE module's class loader. I've attached three Maven projects which reproduce the issue. To reproduce the issue just build the projects, deploy them (don't forget the JBoss module generic-service-api which you can find pre-built inside the project's target directory), run your WildFly and open http://localhost:8080/b-service-war/my-entities/42 in a browser. You should get a ClassCastException. I've also attached a patch which contains a fix. It actually contains two fixes: Using the Java EE module's class loader instead of the interface's JBoss module class loader Getting rid of the LocalInvocationClassCloner, because it has no upside, but a downside which is swallowing/hiding packaging issue If you accept this issue, I'd be willing to commit a fix and create a pull request for you. Regards -- This message was sent by Atlassian JIRA (v7.2.3#72005)