ClassCastException due to wrong class loader after remote EJB invocation inside the same JVM

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