I was posting a similar problem. I think it has to do with the deployment-based scoping. This is my scenario:
App1.ear -> Contains a session bean, registered in JNDI App2.ear -> Contains a session bean, registered in JNDI, which retrieves and invokes a business method on session bean of App1 If I package the two ears without jboss-app.xml, App2 can happily lookup session bean on app1 and invoke its business method. If I package the two apps with jboss-app.xml, I get the following exception: | 18:19:10,671 ERROR [LogInterceptor] RuntimeException in method: public abstract void uk.co.jemos.ucltest2.intf.Session2Session.executeUcl1HelloWorld() throws java.rmi.RemoteException: | java.lang.ClassCastException | at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:229) | at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137) | at uk.co.jemos.ucltest2.ejbs.sessions.Session2Bean.executeUcl1HelloWorld(Session2Bean.java:79) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.invocation.Invocation.performCall(Invocation.java:345) | at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) | at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149) | at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154) | at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:54) | at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) | at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106) | at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335) | at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) | at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153) | at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) | at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) | at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) | at org.jboss.ejb.Container.invoke(Container.java:873) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) | at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805) | at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) | at sun.rmi.transport.Transport$1.run(Transport.java:153) | at java.security.AccessController.doPrivileged(Native Method) | at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) | at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.ClassCastException: $Proxy88 | at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:212) | ... 42 more | | | My interpretation follows: | | Since App2 is loaded in its classloader, when it tries to narrow the home interface of the SB belonging to App1 (which is itself loaded in its own classloader), for the JVM those are two different types (even if it's the same class, this has been loaded by two different class loaders, thus those are two different Java types). | | App2 contained app1-ejb-client.jar as module, but this didn't change a thing. | | | Even if I understand what went wrong here, my question is: what is the utility of deployment-based scoping? | | In the company where I work we often have got App1, App2, App3...AppN deployed on Jboss. Most of those apps share some components (let's say a common component). Sometimes, we make changes to the common component and rebuilt, let's say App3. App1, App2, AppN still have got a dependency on the common component which now is different from the common component deployed with App3. So unless we rebuild all the Apps using the common component we risk versions problems; another possible scenario for problems is when the commons component has been loaded by App1 (therefore the unified repository loads the 'old' commons component) and App3 tries to use the new functionalities. Since the loaded commons component is the old one, an error will be thrown because the new functionalities are not in the loaded class. | | So we thought of deployment-based scoping (i.e. adding jboss-app.xml to ear/META-INF). But then we incur in the ClassCastException above. | | What possible solution could be adopted here? | | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3923155#3923155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3923155 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
