When deploying stateful session bean, it shows via JNDI view

[yair.zaslavsky]

The definition of the bean is:

@Stateful
@Remote(QueryManager.class)
@RemoteBinding(jndiBinding="ams/QueryComposerManagerBean/Remote")
@Local(QueryManager.class)
@LocalBinding(jndiBinding="ams/QueryComposerManagerBean/Local")
public class AMSQueryManagerBean implements QueryManager {
}

JNDI view shows:

QueryComposerManagerBean (class: org.jnp.interfaces.NamingContext)
| | +- RemoteStatefulProxyFactory (proxy: $Proxy170 implements interface org.jboss.ejb3.ProxyFactory)
| | +- Remote (class: java.lang.Object)
| | +- LocalStatefulProxyFactory (class: org.jboss.ejb3.stateful.StatefulLocalProxyFactory)
| | +- Local (class: java.lang.Object)


I manage to lookup it from tomcat, and J2SE clients
I cannot lookup it from a WAR that is a part of the deployed ear (throws class cast exception, this is why i checked the JNDI view).
For stateless session beans, i see Remote and Local are ok in JNDI view.

How can I solve this? (There is no multiple defition in the EAR of the stateful session bean)

[h0ppy]

I have a very similar problem, did you ever find a resolution?

[jaikiran]

You mean, you are seeing a classcastexception while doing the lookup from the war? Have a look at http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassCastExceptions, especially, the JMX console method mentioned over there

[alistairblack]

Hi,

I'm experiencing the same problem as described in the original post. I've read the information within the link regarding ClassCastExceptions but cannot resolve the issue. My EAR file is being packaged via Eclipse (Ganymede) and the Bean itself resides within a JAR at top level described within application.xml. This JAR also appears to be included within the WAR (obviously nested within the EAR file containing the JAR I've just mentioned) within the WEB-INF/lib directory. Is it this duplication of the JAR, and therefore the Stateful session bean class and interface, which is causing the problem?

Many thanks

Alistair

[peterj]

Yes, having the ejb jar file appear both in the ear and the war will cause a problem. The ejb will be created using the class definition from the jar in the ear, and then when code in the war attempts to access it, the jar in the war will be used for the class definition, and those are not the same because of the different classloaders used. Removing the ejb jar from the war should solve the issue.