Hi, I'm seeing a fairly common error message, it would seem: A ClassCastException on the narrow call after retrieving the home interface of an EJB2.

I have read all the docs saying to ensure that Isolation and CallByValue are on so the server is J2EE 1.4 compliant. In 4.0.3SP1, that was sufficient. Unfortunately, in 4.0.5.GA, even after using the installer (default configuration) and clicking the checkbox to turn on CallByValue, I still get the exception at the end of this message.

Do we have confirmation that 4.0.5 didn't break something in this regard? The release notes didn't have any clue in them, and I check the XML files and sure enough they have the right isolation settings, (i.e. the ones that worked in 4.0.3) although some files have changed and the docs are out of date. Still, I trust the installer to set up isolation and callByValue correctly.

Ideas? Something else I should try?

Here is the exception:

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 com.carescience.odmt.web.util.EJBUtil.getAdminHome(EJBUtil.java:42) at com.carescience.dm.ui.data.dao.DMAuthenticationDAO.loadUserByUsername(DMAuthenticationDAO.java:47) at org.acegisecurity.providers.cas.populator.DaoCasAuthoritiesPopulator.getUserDetails(DaoCasAuthoritiesPopulator.java:51) at org.acegisecurity.providers.cas.CasAuthenticationProvider.authenticateNow(CasAuthenticationProvider.java:142) at org.acegisecurity.providers.cas.CasAuthenticationProvider.authenticate(CasAuthenticationProvider.java:122) at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:183) at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45) at org.acegisecurity.ui.cas.CasProcessingFilter.attemptAuthentication(CasProcessingFilter.java:76) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:199) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:108) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:138) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:191) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148) at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90) 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.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.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) 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)Caused by: java.lang.ClassCastException: $Proxy213 at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:212) ... 38 more

Specifically the jmx-console method mentioned over there. That might help you in identifying the issue. I am not sure what has changed between the two server version which you mention, that should result in this behaviour.

Already did that. When I do displayClassInfo on the home interface, I only see one "Instance1" and one "CodeSource". I did the same thing on the remote interface because the docs weren't clear which one I should be getting info on.

Either way, the page says: "If you see multiple 'Instance1' and multiple CodeSources? then this could be the cause of the ClassCastExceptions that you are seeing." But I everything looks fine according to JMX, except that the app doesn't work.

Since you mention this was working in earlier version of JBoss, i dont think your code might be having issues.

Do we have confirmation that 4.0.5 didn't break something in this regard? The release notes didn't have any clue in them, and I check the XML files and sure enough they have the right isolation settings, (i.e. the ones that worked in 4.0.3) although some files have changed and the docs are out of date. Still, I trust the installer to set up isolation and callByValue correctly.

The docs say to change deploy/ear-deployer.xml, turning on Isolated and CallByValue Mine is below (it looks fine to me. The installer set it up right)

<server>
<!-- EAR deployer, remove if you are not using ear deployments -->
<mbean code="org.jboss.deployment.EARDeployer"
name="jboss.j2ee:service=EARDeployer">
<!-- A flag indicating if ear deployments should have their own scoped
class loader to isolate their classes from other deployments.
-->
<attribute name="Isolated">true</attribute>
<!-- A flag indicating if the ear components should have in VM call
optimization disabled.
-->
<attribute name="CallByValue">true</attribute>
</mbean>
</server>

It also says to go to deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml and set Java2ClassLoadingCompliance and UseJBossWebLoader to false. Again, the installer set it correctly

<!-- Get the flag indicating if the normal Java2 parent first class
loading model should be used over the servlet 2.3 web container first
model.
-->
<attribute name="Java2ClassLoadingCompliance">false</attribute>
<!-- A flag indicating if the JBoss Loader should be used. This loader
uses a unified class loader as the class loader rather than the tomcat
specific class loader.
The default is false to ensure that wars have isolated class loading
for duplicate jars and jsp files.
-->
<attribute name="UseJBossWebLoader">false</attribute>

Last, the doc I saw (can't find the link right now) said to change conf/jboss-service and change the NamingService CallByValue setting. Now, in 4.0.5, it appears that NamingService moved (to deploy/naming.sar/META-INF/jboss-service?) And it appears that, right or wrong, the installer didn't set CallByValue to true in that file. I tried it both ways, and I still get the error.

Thus, as you can see, I believe that I (or the installer) have set the config values correctly based on the docs and yet things still don't work on 4.0.5.

I've just tried JEMS 1.2.0 final installer, told it to do a "standard" install, then twiddled the 2 settings mentioned in the install notes, and everything seems to be functioning again as I would expect. I didn't have to compromise my isolated deployment components.