5 Replies Latest reply on Sep 2, 2009 8:33 AM by xmedeko

    Does ClassLoader isolation isolate the Java base classes as

    xmedeko

      We have several version of our EAR (it contains a @Service bean) deployed in the JBoss 5.1.0GA and the class level isolation is set to true in the deployers/ear-deployer-jboss-beans.xml file.

      The deployed EARs are named like corpim_1157.ear, corpim_1158.ear, corpim_1159.ear, corpim_1160.ear.... Each EAR has a lib/jce-jdk13-128.jar library, that is org.bouncycastle implementation. After some time, we have deleted the old versions corpim_1157.ear and then deployed a new version corpim_1161.ear. It has thrown an exception:

      java.lang.IllegalStateException: BaseClassLoader@1e3f171{vfsfile:/home/jboss/jboss-5.1.0.GA/server/prins/deploy/corpim_1157.ear/} classLoader is not connected to a domain (probably undeployed?) for class sun.reflect.ConstructorAccessorImpl


      The service bean executes the code during the startup:

      java.security.Provider provider = new org.bouncycastle.jce.provider.BouncyCastleProvider.BouncyCastleProvider();
      java.security.Security.addProvider( provider );
      java.security.cert.CertificateFactory.getInstance( "X.509", provider.getName() );
      


      It is strange, that the class loader tries to access the undeployed EAR. I would expect it takes BouncyCastleProvider from the current deployment because of the ClassLoader isolation.

      I guess the problem is that java.security.Security stores the provider in the static cache sun.security.jca.Providers, and the cache can contain only one objects with distinct Provider.getName(). This cache is only a singleton for all deployments. Does it mean the Java base classes are not isolated? Is it expected behaviour?

      Thanks
      Andy


        • 1. Re: Does ClassLoader isolation isolate the Java base classes
          jaikiran

           

          After some time, we have deleted the old versions corpim_1157.ear and then deployed a new version corpim_1161.ear. It has thrown an exception:

          java.lang.IllegalStateException: BaseClassLoader@1e3f171{vfsfile:/home/jboss/jboss-5.1.0.GA/server/prins/deploy/corpim_1157.ear/} classLoader is not connected to a domain (probably undeployed?) for class sun.reflect.ConstructorAccessorImpl


          Do you do that when the server is up and running? Please post the entire exception stacktrace and few lines from the console. That will give us an idea as to which deployment is trying to access that classloader.


          While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

          • 2. Re: Does ClassLoader isolation isolate the Java base classes
            xmedeko

            Yes, we deploy/undeploy when the JBoss is running. The problem has occured always during a new deployment.

            After all, I have removed this code from our application, because it was obsolete. But anyway, I would like to understand why this problem has occured, because we need to use classloader isolation and have more version of our application in one JBoss.

            The full stack trace (classes starting with cz.* is our application).


            2009-08-31 18:08:22,825 SEVERE [cz.modis.kernel.app.authentication.CertificateAuthorityInfo] (HDScanner) In initializing the CertificateFactory
            java.security.cert.CertificateException: X.509 not found
             at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:200)
             at cz.modis.kernel.app.authentication.CertificateAuthorityInfo.<clinit>(CertificateAuthorityInfo.java:58)
             at java.lang.Class.forName0(Native Method)
             at java.lang.Class.forName(Class.java:169)
             at cz.modis.util.Convert.getClass(Convert.java:74)
             at cz.modis.kernel.app.config.DetailField.setType(DetailField.java:149)
             at cz.modis.kernel.app.config.ConfigurationBuilder_1_0.readTransaction(ConfigurationBuilder_1_0.java:502)
             at cz.modis.kernel.app.config.ConfigurationBuilder_1_0.readConfiguration(ConfigurationBuilder_1_0.java:196)
             at cz.modis.kernel.app.config.ConfigurationBuilder_1_0.readConfiguration(ConfigurationBuilder_1_0.java:160)
             at cz.modis.kernel.app.config.ConfigurationBuilder_1_0.readConfiguration(ConfigurationBuilder_1_0.java:126)
             at cz.modis.kernel.app.config.Configuration.readAllModulesConfiguration(Configuration.java:638)
             at cz.modis.kernel.app.config.Configuration.readAllModulesConfiguration(Configuration.java:622)
             at cz.modis.kernel.app.transaction.Layer.init(Layer.java:303)
             at cz.modis.kernel.app.transaction.Layer.init(Layer.java:201)
             at cz.modis.ee.server.ModisConfigurationBean.start(ModisConfigurationBean.java:110)
             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:597)
             at org.jboss.ejb3.service.ServiceContainer.invokeOptionalMethod(ServiceContainer.java:369)
             at org.jboss.ejb3.service.ServiceContainer.lockedStart(ServiceContainer.java:264)
             at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:884)
             at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source)
             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
             at java.lang.reflect.Method.invoke(Method.java:597)
             at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
             at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
             at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
             at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
             at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
             at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
             at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
             at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
             at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
             at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
             at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
             at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
             at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
             at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
             at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
             at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
             at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
             at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
             at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
             at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
             at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
             at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
             at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
             at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
             at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
             at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
             at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
             at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
             at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
             at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
             at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
             at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
             at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
             at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
             at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
             at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
             at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
             at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
             at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
             at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
             at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
             at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
             at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
             at java.lang.Thread.run(Thread.java:619)
            Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: X.509, provider: BC, class: org.bouncycastle.jce.provider.JDKX509CertificateFactory)
             at java.security.Provider$Service.newInstance(Provider.java:1245)
             at sun.security.jca.GetInstance.getInstance(GetInstance.java:220)
             at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
             at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:195)
             ... 75 more
            Caused by: java.lang.IllegalStateException: BaseClassLoader@1e3f171{vfsfile:/home/jboss/jboss-5.1.0.GA/server/prins/deploy/corpim_1157.ear/} classLoader is not connected to a domain (probably undeployed?) for class sun.reflect.ConstructorAccessorImpl
             at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:793)
             at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
             at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
             at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
             at sun.misc.Unsafe.defineClass(Native Method)
             at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
             at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
             at java.security.AccessController.doPrivileged(Native Method)
             at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
             at sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:76)
             at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:30)
             at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
             at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
             at java.lang.Class.newInstance0(Class.java:355)
             at java.lang.Class.newInstance(Class.java:308)
             at java.security.Provider$Service.newInstance(Provider.java:1221)
             ... 78 more



            Thanks
            Andy

            • 3. Re: Does ClassLoader isolation isolate the Java base classes
              jaikiran

              Where is the class cz.modis.util.Convert packaged? And please provide the code in your cz.modis.kernel.app.config.DetailField.setType method and also the configurations that you are using to isolate classloading.

              • 4. Re: Does ClassLoader isolation isolate the Java base classes
                xmedeko

                Basically, all this code just do Class.forName("cz.modis.kernel.app.authentication.CertificateAuthorityInfo") and the class CertificateAuthorityInfo had the static initilizar with the code you can see in my first post.

                (The application reads from XML which classes to load. The cz.modis.util.Convert.getClass() just converts some strings like "int" to java basic classes like Integer.class, if the Convert.getClass() does not find the simple conversion, then it calls Class.forName().)

                It seems working so far. When I deploy a new version of our application with some new classes in the EAR, the new classes are properly used. The only problem was with that

                java.security.Security.addProvider( provider );
                java.security.cert.CertificateFactory.getInstance( "X.509", provider.getName() );
                


                I use class loader isolation in deployers/ear-deployer-jboss-beans.xml file:

                <bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
                 <property name="isolated">true</property>
                 </bean>
                




                • 5. Re: Does ClassLoader isolation isolate the Java base classes
                  xmedeko

                  If such behaviour is a bug, I can try to make some minimal EAR to demonstrate this behaviour.