JBossDeveloper

obj.getClass().getClassLoader().toString() should do the trick.

Cool, nice to see that it is working out.

Hmm, that leaves two bugs. Note to devs:

- ear flat class path not working

- remote interface should be able to traverse class loader boundaries

And I'll leave the thread with another class loading bug hunting trick:

obj.getClass().getProtectDomain().getCodeSource().getLocation().toString()

If you are working with a single ear deployment I can see that it would be fairly easy to insure that there is only one copy of they interface in the deployment.  But what about situations where an ear/war/whatever needs to invoke an EJB contained in a different ear/war/whatever.

Stumbled on the same problem - any solutions or work-arounds? Need to address from one external .war into an .ear.

Just wanted to add, that I ran into the same issue, when deploying an ear and war separately and trying to inject a remote ejb into a managed bean in war:

Caused by: java.lang.IllegalArgumentException: Can not set com.axatech.ch.services.IrgendeinServiceRemote field org.icefaces.application.showcase.facelets.navigation.NavigationBean.irgendeinService to com.axatech.ch.services.IrgendeinServiceRemote$$$view2
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:680)

As Carlo wrote later on, interface classes should really be able to pass classloader borders.

Replying to my own question - yes there is a workaround. Got a tip from Mohan that elaborates his post above and says that you have to avoid duplicates within the entire AS of all interface classes (and, I think, some classes used by the interface).

Thus I (and Mohan) make different client wars for local deployment (that do not include the interface etc) and remote deployment (that do include the interface).

I got a very preliminary patch here https://github.com/wolfc/jboss-as/tree/AS7-1658

It mem leaks, so it is not useful yet. Also creation of MarshallingInvocationHandler is slow.

But you can try it out to see if you run into other issues.

I've rebuilt your patched version but still can't cast the received "view" to the relevant @Local interface. Receive following exception during an injection of an @EJB into ManagedBean field:

java.lang.IllegalArgumentException: Can not set bg.regel.backend.api.login.LoginEJBLocal field bg.regel.web.beans.LoginManagedBean.loginEJB to bg.regel.backend.api.login.LoginEJBLocal$$$view1

at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) [:1.7.0]

    at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) [:1.7.0]

    at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81) [:1.7.0]

    at java.lang.reflect.Field.set(Field.java:680) [:1.7.0]

Can you post the entire stack trace?

I suspect that injection does not run in the correct context.

Ah I didn't read the fine details of your post. An @Local interface must come from a shared class loader / library, else you can never pass parameters by reference.