7 Replies Latest reply on Jan 17, 2007 2:20 PM by jflinchbaugh

    Isolation/CallByValue on 4.0.5

    dhannum

      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

        • 1. Re: Isolation/CallByValue on 4.0.5
          johnflinchbaugh

          I'm having the same difficulties trying to move previously working apps from 4.0.4 to 4.0.5.

          • 2. Re: Isolation/CallByValue on 4.0.5
            jaikiran

            Have a look at:

            http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassCastExceptions

            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.

            • 3. Re: Isolation/CallByValue on 4.0.5
              dhannum

              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.

              Other ideas?

              • 4. Re: Isolation/CallByValue on 4.0.5
                jaikiran

                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.


                Maybe you can post the contents of the xml that you checked for.

                • 5. Re: Isolation/CallByValue on 4.0.5
                  dhannum

                  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.

                  Ideas?

                  Thanks
                  Dan

                  • 6. Re: Isolation/CallByValue on 4.0.5
                    vbar3159

                    Look here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885650#3885650

                    I had exactly the same problem and after repackaging my EAR - removing duplicit classes frlom WAR module, the error disappeared !!

                    I hope this will help you
                    Vaclav

                    • 7. Re: Isolation/CallByValue on 4.0.5
                      jflinchbaugh

                      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.