first of all, I have to say that the application I am developing work ok using EJB3 preview 5 and Jboss 4.0.1sp1.This application has several session beans (stateless and stateful). Each bean has a interface with the @Remote annotation. Deploy goes ok, without problems neither warnings...Now, when inside the application (a war) I try to access to a bean the wrong class is returned, while if I get the bean from a client (in a suite of tests that I have outside JBoss everything goes ok).

I am having more problems with jboss4.0.1sp1 so I've decided to give a new try to jboss4.0.3RC1 to see if I find where I might have something wrong...I've tried to see why the server is throwing a ClassCastException when doing from a webapp (and not from a standalone client outside Jboss):

But, surprisingly, if I get the interfaces of this object using reflection I get two interfaces:

- my.company.UserHandler - org.jboss.ejb3.JBossProxy

Weird, if one of the interfaces is UserHandler (as expected) why is the cast throwing an exception, how can the instanceof return false if one of the interfaces implemented by the Proxy is UserHandler? Another question, how can the application from the server fail and the standalone test client work? Could it be a classpath issue?

The only difference I see is that in the server I have to copies of UserHandler (one inside the *.par file) and another inside a jar (the jar that my application has in the WEB-INF/lib to be able to use the session bean).

With the tomcat classloader settings that ship with 4.0.3 you will always load the copy from WEB-INF/lib from the web layer, and this uses a different classloader from the one used inside the ejb layer. Two classes loaded by different classloaders are not the same to the java runtime, and will cause runtime exceptions when you try to assign a reference to one to the other.

Try removing UserHandler from the jar in WEB-INF/lib, this will make sure that there is only one copy of the class ever loaded.