JBoss 4.04 EJB3 lookup: classCastException on proxy object

[dekadence]

Greetings,

Similiar problem was already solved here, but it came to no help for my case.
I have simple bean LoginStatistcsBean code:

@Stateless
@Remote(LoginStatisticsBeanBI.class)
@Local(LoginStatisticsBeanBI.class)
public class LoginStatisticsBean implements LoginStatisticsBeanBI {

 public LoginStatisticsBean() {
 }
 public helllo(){
 }
}

I have an interface for it used as both local and remote code:

@Remote
@Local
public interface LoginStatisticsBeanBI {

 public void hello();
}

But my ,,client'' is a FOSessionListener used to record session create/destroy events over JbossPortal serrvlet, placed in jboss-portal.sar/portal-server.war/META-INF/lib. So I created a client-jar archive containing my LoginStatisticsBeanBI interface and placed it into same folder. snippet for lookup:

Object obj = ic.lookup("LoginStatisticsBean/remote");
LoginStatisticsBeanBI bi= (LoginStatisticsBeanBI) obj;

Bean is correctly deployed,and bounded :

+- LoginStatisticsBean (class: org.jnp.interfaces.NamingContext)
 | +- local (proxy: $Proxy135 implements interface com.giag.fo.statistics.ejb.interfaces.LoginStatisticsBeanBI,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBLocalObject)
 | +- remote (proxy: $Proxy133 implements interface com.giag.fo.statistics.ejb.interfaces.LoginStatisticsBeanBI,interface org.jboss.ejb3.JBossProxy,interface javax.ejb.EJBObject)

and due to this outcome of jndi bounding it is obvious that proxy objects implements LoginStatisticsBeanBI

But after either rocal or remote lookup, the returned proxy objects cant be casted to The interface.
exception code:

10:25:01,453 ERROR [[/]] Session event listener threw exception
java.lang.ClassCastException: $Proxy133
 at com.giag.fo.statistics.sessionListener.FOSessionListener.sessionDestroyed(FOSessionListener.java:76)
 at org.apache.catalina.session.StandardSession.expire(StandardSession.java:687)
 at org.apache.catalina.session.StandardSession.expire(StandardSession.java:645)
 at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1090)
 at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:149)
 at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.after(SessionInvalidatorInterceptor.java:146)
 at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:96)
 at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
 at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
 at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
 at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
 at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
 at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
 at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNext(TransactionInterceptor$invoke_N5143606530999904530.java)
 at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
 at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
 at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
 at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
 at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
 at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at com.giag.fo.statistics.filters.LoginFilter.doFilter(LoginFilter.java:53)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at com.giag.fo.statistics.filters.LoginFilter.doFilter(LoginFilter.java:53)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
 at java.lang.Thread.run(Thread.java:595)

could this be caused by the location of client-jar[containing my bean's interface] in portal-servlet.war archive?
or is there any other possibility to make my bean visible for the SessionListener placed in portal-server.war archive?
Thank you very much for your time and effort

Matus

[jaikiran]

I have an interface for it used as both local and remote code

I am not sure, whether its possible to have the same interface for both local and remote interfaces. I mean even though the methods might be same, i guess you need to have 2 separate interfaces for each of them. Does it work, if you create separate interfaces for local and remote?

[salewski]

From the EJB3 spec (4.6.5, page 95):

"The same business interface cannot be both a local and a remote business interface of the bean."

In JBoss 4.0.5.GA, it seemed that using the same Java interface class for both local and remote EJB business interfaces worked for most configurations; I can't say what the behavior in 4.0.4 is, but I wouldn't be surprised if it was similar to that for 4.0.5.GA. Here is a related jira issue, which indicates the behavior was fixed for JBoss 4.2.x:

http://jira.jboss.com/jira/browse/EJBTHREE-751

[peterj]

This sure does sound like a class loader issue. Possibly the EJB container instantiated the $Proxy133 object with one class loader and your code is using a different class loader, so even though both of the class loaders have the interface declaration, those interfaces are not the same.

I suggest moving the EJB JAR file out of the WAR file and placing it into the deploy directory. If that works, you can always repackage your app as an EAR containing the EJB JAR and your WAR.

[dekadence]

thank you all for your interest,

It is possible to use the same interface for both local and remote invokation.

the problem was, as PeterJ pointed out, in classloading. after moving client-jar out of portal-server.war archive to jboss-portal.sar/lib/ problem dissappeared.

Thank you again