13 Replies Latest reply on May 12, 2010 10:39 AM by kabirkhan

    ClassPool bootstrap refactoring

    kabirkhan

      Following on from http://community.jboss.org/message/539041#539041 I have started refactoring how the ClassPools are initialized during bootstrap and moving code into the classpools project. The following (uncommitted, but working) test in ClassPools demonstrates how I see this working in the bootstrap.

       

         /**
          * Simulates the steps to be taken during AS bootstrap
          */
         public void testBootstrap() throws Exception
         {
            //Initialize the config. This wires together the parts of the system
            JBossClClassPoolConfig config = JBossClClassPoolConfig.getInstance();
            assertNotNull(config.getClassPoolFactory());
            assertNotNull(config.getClassPoolRepository());
            assertNotNull(config.getDomainRegistry());
            assertNotNull(config.getRegisterModuleCallback());
            assertNull(config.getClassLoading());
      
            //Check that the classpool factory works before we have deployed the classpool system
            ClassLoader urlCl = createChildURLLoader(null, JAR_A_URL); 
            ClassPool urlPool = config.getClassPoolRepository().registerClassLoader(urlCl);
            assertNotNull(urlPool);
            CtClass aUrl = urlPool.get(CLASS_A);
            CtClass stringUrl = urlPool.get(String.class.getName());
      
            //Install the bean to get notified when ClassLoading is installed
            BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("JBossClClassPoolConfig", JBossClClassPoolConfig.class.getName());
            builder.setFactoryClass(JBossClClassPoolConfig.class.getName());
            builder.setFactoryMethod("getInstance");
            ValueMetaData inject = builder.createContextualInject(null, null, AutowireType.BY_NAME, InjectOption.CALLBACK);
            ((AbstractInjectionValueMetaData)inject).setValue("ClassLoading");
            builder.addPropertyMetaData("classLoading", inject);
            getDelegate().deploy(builder.getBeanMetaData());
      
            //Deploy the ClassLoading. This causes the RegistryModuleCallback
            //to get installed as a module registry in ClassLoading
            getDelegate().deployCommon();
            assertNotNull(config.getClassLoading());
      
            testScenario = new ClassPoolTestScenario<CLDeploymentBuilder>(getClassLoaderFactory(), config.getClassPoolRepository());
      
            ClassPool poolA = testScenario.createLoader(new CLDeploymentBuilder("A", JAR_A_URL));
            CtClass aDomain = poolA.get(CLASS_A);
            assertNotSame(aUrl, aDomain);
            assertSame(stringUrl, poolA.get(String.class.getName()));
      
            ClassPool poolB = testScenario.createLoader(new CLDeploymentBuilder("B", JAR_B_URL));
            assertSame(aDomain, poolB.get(CLASS_A));
         }
      

       

      The JBossClClassPoolConfig singleton wires together a lot of the things that are needed for running this in AS (getters ommitted)

       

      public class JBossClClassPoolConfig
      {
         private static volatile JBossClClassPoolConfig config;  
         private final DomainRegistry domainRegistry;
         private final RegisterModuleCallback registerModuleCallback;
         private ClassLoading classLoading;
         private JBossClDelegatingClassPoolFactory classPoolFactory;
         private ClassPoolRepository classPoolRepository;
         private JBossClClassPoolConfig(DomainRegistry domainRegistry, RegisterModuleCallback registerModuleCallback, JBossClDelegatingClassPoolFactory classPoolFactory)
         {
            this.domainRegistry = domainRegistry;
            this.registerModuleCallback = registerModuleCallback;
            this.classPoolFactory = classPoolFactory;
            classPoolRepository = ClassPoolRepository.getInstance();
            classPoolRepository.setClassPoolFactory(classPoolFactory);
         }
         public static JBossClClassPoolConfig getInstance()
         {
            if (config == null)
            {
               config = initialize();
            }
            return config;
         }
         
         private synchronized static JBossClClassPoolConfig initialize()
         {
            if (config != null)
               return config;
            
            DomainRegistry domainRegistry = new VFSClassLoaderDomainRegistry();
            RegisterModuleCallback registerModuleCallback = new RegisterModuleCallback(domainRegistry);
            JBossClDelegatingClassPoolFactory classPoolFactory = new JBossClDelegatingClassPoolFactory(domainRegistry, registerModuleCallback);
            
            return new JBossClClassPoolConfig(domainRegistry, registerModuleCallback, classPoolFactory);
         }
         
         /**
          * Set the classLoading. This should be set via a property 
          * by the MC
          * 
          * @param cl the classLoading to set
          */
         public void setClassLoading(ClassLoading cl)
         {
            if (cl != null)
               cl.addModuleRegistry(registerModuleCallback);
            else if (classLoading != null)
               classLoading.removeModuleRegistry(registerModuleCallback);
            
            classLoading = cl;
         }
      }
      

       

      So basically all the AS bootstrap will need to do is to call JBossClClassPoolConfig.getInstance() to initialize the classpool parts, and then deploy the JBossClClassPoolConfig bean whose purpose is to add the RegisterModuleCallback as a module registry in ClassLoading once that is deployed.

       

      With this in place and with a few small changes to how the aop classes work, what is in bootstrap/aop.xml will reuse things from JBossClClassPoolConfig where appropriate.

        • 1. Re: ClassPool bootstrap refactoring
          alesj

          But how does this relate to classes or beans deployed before JBoss-CL is in place; which is in classloader.xml in bootstrap/ ?

           

          Afais, the config should be completely generic,

          and then jboss-cl would come in as an impl detail.

           

          Perhaps some sort of lookup chain?

          * something that knows how to handle bootstrap lookups

          * other impl details such as jboss-cl

           

          Since jboss-cl handling impl should also know how to handle boostrap lookups,

          we can/could remove/replace the first element in this chain, once jboss-cl is in place.

          • 2. Re: ClassPool bootstrap refactoring
            kabirkhan

            AbstractMCServerBase now does (once it is working properly I will move the extra code to LifecycleEventListeners)

             

             

               @Override
               protected void doInitialize() throws IllegalStateException, InvalidConfigurationException, LifecycleEventException
               {
                  // NEW CODE - 1
                  /*
                   * Make sure we have the correct classpools set up  
                   */
                  //Initialize jboss-reflect to use the correct classpools
                  JBossClClassPoolConfig config = JBossClClassPoolConfig.getInstance();
                  RepositoryClassPoolFactory factory = new RepositoryClassPoolFactory(config.getClassPoolRepository());
                  JavassistTypeInfoFactoryImpl.setPoolFactory(factory);
                  // NEW CODE - 1 - END
            
                  /*
                   * We need to start the bootstrap here so we can set the kernel
                   * before we fire start kernel events 
                   */
                  this.initializeBootstrap();
            
                  // Call Super implementation
                  super.doInitialize();
            
                  // NEW CODE - 2
            
                  //Install the bean configuring the classpools
                  BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("JBossClClassPoolConfig", JBossClClassPoolConfig.class.getName());
                  builder.setFactoryClass(JBossClClassPoolConfig.class.getName());
                  builder.setFactoryMethod("getInstance");
                  ValueMetaData inject = builder.createContextualInject(null, null, AutowireType.BY_NAME, InjectOption.CALLBACK);
                  //TODO add name to BeanMetaDataBuilder
                  ((AbstractInjectionValueMetaData)inject).setValue("ClassLoading");
                  builder.addPropertyMetaData("classLoading", inject);
            
                  try
                  {
                     getKernel().getController().install(builder.getBeanMetaData());
                  }
                  catch (Throwable e)
                  {
                     // AutoGenerated
                     throw new RuntimeException(e);
                  }
                  // NEW CODE - 2 - END
            
            
               }
             
            

            The stuff in 1) sets up the classloader system so it understands the bootstrap classloaders

            The stuff in 2) "listens" for ClassLoading and registers the container as a module Handler

            • 3. Re: ClassPool bootstrap refactoring
              kabirkhan

              https://jira.jboss.org/jira/browse/CLASSPOOL-7

               

              As part of this, I have had to refactor things a bit so there is another module called jbosscl-as which contains the reference to

              AbstractDeploymentClassLoaderPolicyModule previously done in VFSClassLoaderDomainRegistry. The reason for this is that ADCLPM is not available until the deployers.xml classloader is deployed, so I was getting some errors trying out this in the AS bootstrap.

               

              The next step is to change aop.xml to reuse the classpools from the bootstrap.

              • 4. Re: ClassPool bootstrap refactoring
                kabirkhan

                I have modified JBoss AOP and my local bootstrap/aop.xml to understand the new classpool setup.  AS boots up properly with this and all the aop AS testsuite passes apart from ScopedWovenDependencyTestCase and NotWovenScopedDependencyTestCase. I have reproduced the problem I see for those in kernel with the following test

                 

                 

                   public void testInstallAndUninstallDependencyWithExtraState() throws Throwable
                   {
                      getKernel().getController().addState(ControllerState.newState(), ControllerState.INSTALLED);
                      installAndUninstallDependencyWithExtraState();
                
                      //context2 goes in scoped controller and depends on context1
                      ControllerContext context2 = assertInstall(offSetNumber(1), "Name2", ControllerState.INSTANTIATED);
                      //context1 goes in main controller
                      ControllerContext context1 = assertInstall(offSetNumber(0), "Name1", ControllerState.INSTALLED);
                      context1 = assertContext("Name1");
                      context2 = assertContext("Name2");
                
                      assertUninstall("Name1"); //Gives error
                      assertContext("Name2", ControllerState.INSTANTIATED);
                      assertUninstall("Name2");
                      assertNotInstalled("Name1");
                      assertNotInstalled("Name2");
                   }
                 
                

                 

                The error is

                1357 WARN  [AbstractKernelController] Error uninstalling from Installed: name=Name2 state=Installed

                java.lang.NullPointerException

                at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1632)

                at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)

                at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1541)

                at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)

                at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:760)

                at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:673)

                at org.jboss.test.kernel.dependency.support.TestUtil.uninstall(TestUtil.java:110)

                at org.jboss.test.kernel.dependency.support.ScopedTestUtil.uninstall(ScopedTestUtil.java:81)

                at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.uninstall(OldAbstractKernelDependencyTest.java:118)

                at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.assertUninstall(OldAbstractKernelDependencyTest.java:151)

                at org.jboss.test.kernel.dependency.test.ExtraStateTestCase.testInstallAndUninstallDependencyWithExtraState(ExtraStateTestCase.java:95)

                It is getting confused somewhere about the ControllerStateModel.ControllerStateWrappers

                • 5. Re: ClassPool bootstrap refactoring
                  kabirkhan

                  Kabir Khan wrote:

                  It is getting confused somewhere about the ControllerStateModel.ControllerStateWrappers

                  Fixed for https://jira.jboss.org/jira/browse/JBKERNEL-119

                  • 6. Re: ClassPool bootstrap refactoring
                    kabirkhan

                    The AS testsuite aop tests and smoke tests now all pass in my local copy.

                     

                    I need to refactor what I have done for the bootstrap a bit, and then I need releases of:

                    • bootstrap
                    • classpool
                    • reflect
                    • kernel
                    • aop

                     

                    Andrew has volunteered to do bootstrap, and I will do the rest.

                    • 7. Re: ClassPool bootstrap refactoring
                      kabirkhan

                      The attached patch contains my changes to bootstrap. I still have not refactored it into LifecycleEventHandlers since this needs to happen exactly where it currently does. The initialization of JBossClClassPoolConfig could possibly be moved into one, but the

                      JBossClClassPoolConfig bean needs to be installed before AbstractJBossASServerBase.doInitialize() calls

                      setupBootstrapDescriptorsFromBootstrapUrl().

                      • 8. Re: ClassPool bootstrap refactoring
                        kabirkhan

                        I have committed my changes to AOP against https://jira.jboss.org/jira/browse/JBAOP-788. I've tested the jars and the new aop.xml in AS 5.1.0 and it seems to work well. Tomorrow I will make sure the install script works for AS 5.1 (so far I have been updating the jars and aop.xml manually) and AS 4.2.3, and run the aop testsuites for both before closing the issue and releasing AOP 2.2.1.

                        • 9. Re: ClassPool bootstrap refactoring
                          kabirkhan

                          I ran the tests. In AS 4 it is fine apart from

                           

                           

                           

                          $more output/reports/TEST-org.jboss.test.aop.test.ScopedAttachUnitTestCase.txt
                          Testsuite: org.jboss.test.aop.test.ScopedAttachUnitTestCase
                          Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 2.041 sec
                          Testcase: testPOJOAdvised1 took 0.276 sec
                          Testcase: testPOJOAdvised2 took 0.115 sec
                          Testcase: testExpectedValues1 took 0.088 sec
                          Testcase: testExpectedValues2 took 0.073 sec
                          Testcase: testScoped1 took 0.324 sec
                          Testcase: testScoped2 took 0.275 sec
                                  Caused an ERROR
                          null
                          javax.management.RuntimeMBeanException
                                  at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176)
                                  at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163)
                                  at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
                                  at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
                                  at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
                                  at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
                                  at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
                                  at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
                                  at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
                                  at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
                                  at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
                                  at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
                                  at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
                                  at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
                                  at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
                                  at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
                                  at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
                                  at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
                                  at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
                                  at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
                                  at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
                                  at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
                                  at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818)
                                  at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419)
                                  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
                                  at sun.rmi.transport.Transport$1.run(Transport.java:159)
                                  at java.security.AccessController.doPrivileged(Native Method)
                                  at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
                                  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
                                  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
                                  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
                                  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
                                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
                                  at java.lang.Thread.run(Thread.java:637)
                          Caused by: java.lang.RuntimeException: Error generating joinpoint class for joinpoint Constructor[constructor=public org.jboss.test.aop.scopedattach.POJO()]
                                  at org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:310)
                                  at org.jboss.aop.instrument.JoinPointGenerator.access$300(JoinPointGenerator.java:77)
                                  at org.jboss.aop.instrument.JoinPointGenerator$GenerateJoinPointClassAction$2.generateJoinPointClass(JoinPointGenerator.java:1730)
                                  at org.jboss.aop.instrument.JoinPointGenerator.generateJoinPointClass(JoinPointGenerator.java:250)
                                  at org.jboss.aop.GeneratedClassAdvisor.generateJoinPointClass(GeneratedClassAdvisor.java:1059)
                                  at org.jboss.test.aop.scopedattach.POJO$POJOAdvisor.POJOAdvisor_new_$aop(POJO$POJOAdvisor.java)
                                  at org.jboss.test.aop.scopedattach.POJO.POJO_new_$aop(POJO.java)
                                  at org.jboss.test.aop.scopedattach.ScopedTester.testScoped(ScopedTester.java:113)
                                  at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
                                  ... 44 more
                          Caused by: javassist.CannotCompileException: Error compiling. Code
                          {super($);isForInstanceAdvisor=($1.getAdvisor() instanceof org.jboss.aop.InstanceAdvisor);around2 = getAround2();around3 = getAround3();around4 = getAround4();around5 = getAround5();around6 = getAround6();}
                                  at org.jboss.aop.instrument.JoinPointGenerator.createPublicConstructor(JoinPointGenerator.java:1120)
                                  at org.jboss.aop.instrument.JoinPointGenerator.createConstructors(JoinPointGenerator.java:1019)
                                  at org.jboss.aop.instrument.JoinPointGenerator.generateJoinpointClass(JoinPointGenerator.java:370)
                                  at org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:285)
                                  ... 56 more
                          Caused by: javassist.CannotCompileException: [source error] no such a constructor
                                  at javassist.CtBehavior.setBody(CtBehavior.java:409)
                                  at javassist.CtBehavior.setBody(CtBehavior.java:375)
                                  at javassist.CtConstructor.setBody(CtConstructor.java:216)
                                  at javassist.CtNewConstructor.make(CtNewConstructor.java:102)
                                  at org.jboss.aop.instrument.JoinPointGenerator.createPublicConstructor(JoinPointGenerator.java:1113)
                                  ... 59 more
                          Caused by: compile error: no such a constructor
                                  at javassist.compiler.MemberCodeGen.atMethodCallCore2(MemberCodeGen.java:593)
                                  at javassist.compiler.MemberCodeGen.atMethodCallCore(MemberCodeGen.java:575)
                                  at javassist.compiler.MemberCodeGen.atCallExpr(MemberCodeGen.java:523)
                                  at javassist.compiler.JvstCodeGen.atCallExpr(JvstCodeGen.java:243)
                                  at javassist.compiler.ast.CallExpr.accept(CallExpr.java:45)
                                  at javassist.compiler.CodeGen.atStmnt(CodeGen.java:337)
                                  at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
                                  at javassist.compiler.CodeGen.atStmnt(CodeGen.java:350)
                                  at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
                                  at javassist.compiler.CodeGen.atMethodBody(CodeGen.java:291)
                                  at javassist.compiler.Javac.compileBody(Javac.java:222)
                                  at javassist.CtBehavior.setBody(CtBehavior.java:401)
                                  ... 63 more

                           

                           

                          In AS 5 all tests are fine apart from

                           

                           

                          $more output/reports/TEST-org.jboss.test.aop.test.RemotingUnitTestCase.txt

                          Testsuite: org.jboss.test.aop.test.RemotingUnitTestCase

                          Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 6.848 sec

                           

                          Testcase: testRemoting took 0.227 sec

                                  Caused an ERROR

                          org/jboss/classpool/spi/ClassPoolRepositoryCallback

                          java.lang.NoClassDefFoundError: org/jboss/classpool/spi/ClassPoolRepositoryCallback

                                  at org.jboss.aop.AspectManager.initManager(AspectManager.java:267)

                                  at org.jboss.aop.AspectManager.instance(AspectManager.java:246)

                                  at org.jboss.aop.AspectManager.instance(AspectManager.java:235)

                                  at org.jboss.aop.proxy.ClassProxyFactory.getProxyClass(ClassProxyFactory.java:111)

                                  at org.jboss.aop.proxy.ClassProxyFactory.newInstance(ClassProxyFactory.java:152)

                                  at org.jboss.aop.proxy.ClassProxyFactory.newInstance(ClassProxyFactory.java:146)

                                  at org.jboss.aop.proxy.MarshalledClassProxy.readResolve(MarshalledClassProxy.java:58)

                                  at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)

                                  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)

                                  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)

                                  at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)

                                  at java.rmi.MarshalledObject.get(MarshalledObject.java:142)

                                  at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:134)

                                  at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)

                                  at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)

                                  at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)

                                  at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)

                                  at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)

                                  at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)

                                  at $Proxy0.invoke(Unknown Source)

                                  at org.jboss.test.aop.test.RemotingUnitTestCase.testRemoting(RemotingUnitTestCase.java:62)

                                  at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)

                                  at junit.extensions.TestSetup$1.protect(TestSetup.java:21)

                                  at junit.extensions.TestSetup.run(TestSetup.java:25)

                          Caused by: java.lang.ClassNotFoundException: org.jboss.classpool.spi.ClassPoolRepositoryCallback

                                  at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

                                  at java.security.AccessController.doPrivileged(Native Method)

                                  at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

                                  at java.lang.ClassLoader.loadClass(ClassLoader.java:315)

                                  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)

                                  at java.lang.ClassLoader.loadClass(ClassLoader.java:250)

                                  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)

                           

                          The same error occurs for the other tests in RemotingUnitTestCase as well. ClassPoolRegistryCallback has been there since Alpha1, so I guess it is a classloader issue. I think remember Flavia mentioning something once, but not exactly what?

                           

                          I'll try to dig in to the errors tomorrow, although I am not sure how much time I will spend on this since we are only really targeting AS 6 with the current AOP releases, supporting previous AS versions is just us "being nice".

                          • 10. Re: ClassPool bootstrap refactoring
                            alrubinger

                            Corrected the failing tests, made a couple other lil' tweaks.

                             

                            https://jira.jboss.org/jira/browse/JBBOOT-134

                             

                            Still something I'd like to investigate is moving some of these bits to event handlers or elsewhere.  This patch brings in a lot of dependencies I'd like to understand/justify.  If this is primarily for AS, what's the overhead in pure MC servers, where this is placed?  If the answer is more than "nothing", we may have to extract this stuff out a bit so pure MCServer performance doesn't deteriorate.

                             

                            S,

                            ALR

                            • 11. Re: ClassPool bootstrap refactoring
                              kabirkhan

                              Andrew Rubinger wrote:

                               

                              Corrected the failing tests, made a couple other lil' tweaks.

                               

                              https://jira.jboss.org/jira/browse/JBBOOT-134

                               

                              Still something I'd like to investigate is moving some of these bits to event handlers or elsewhere.  This patch brings in a lot of dependencies I'd like to understand/justify.  If this is primarily for AS, what's the overhead in pure MC servers, where this is placed?  If the answer is more than "nothing", we may have to extract this stuff out a bit so pure MCServer performance doesn't deteriorate.

                               

                              S,

                              ALR

                              I agree these classpool bits should not be hard-coded in AbstractMcServerBase.doInitialize(). If the events and event handlers can be made more  fine-grained or "precise" as to when they occur (as mentioned what I added must happen in *exactly* the place it does, although it might be possible to move the installation of the config bean into MC before the call to super.initialize()) then we should do that. The quick way would be to just add two new events, PRE_BOOTSTRAP and POST_BOOTSTRAP and raise them from where I am doing so, but I don't want to mess up your code if you have other ideas :-)

                               

                              This is primarily for AS since what my new stuff does is basically to set up javassist classpools understanding the AS classloading, normal MC setups probably will not need to do that, or might need to do something else.

                               

                              The overhead is installing a new bean waiting for the ClassLoading bean to be installed, which then installs itself as a ModuleRegistry in the ClassLoading bean. This ModuleRegistry then gets notified as classloader Modules are added/removed and does some work. So the overhead isn't exactly "nothing", so it should go somewhere else once we can have the event handlers triggered where I need them. I guess these event listeners could go into a different module in bootstrap or elsewhere. As long as the jars containing them are on the classpath, I think AS Main could just call registerEventHandler() after creating the server instance but before initializing it.

                              • 12. Re: ClassPool bootstrap refactoring
                                kabirkhan

                                IRC discussion

                                 

                                 

                                 

                                kkhan:ping ALR
                                [14:24]ALR:kkhan: Hey
                                [14:24]kkhan:ALR: Regarding my bootstrap stuff I think you're right
                                [14:24] ggear joined the chat room.
                                [14:24] ggear was granted voice by ChanServ.
                                [14:25]kkhan:too many dependencies on classpools and other stuuff
                                [14:25]ALR:kkhan: Yup, saw your post.
                                [14:25]kkhan:ALR: Are you ok with me adding the correct hooks for events where I need them, or do you prefer doing so yourself
                                [14:25]ALR:Also we should be making sure all commits/features get testied
                                [14:26]ALR:kkhan: Sure, you can add them.  I'll give some opinions and help guide as you need.
                                [14:26]kkhan:ALR: Yeah, what I had wasn't really meant to be committed, it was more a basis for further instructions
                                [14:26]kkhan:*further discussion
                                [14:26]ALR:kkhan: Ah OK.  I put it in to facilitate testing
                                [14:26]ALR:But hadn't really planned on releasing like that
                                [14:26]ALR:kkhan: I'll reply to your post, but also
                                [14:26]ALR::
                                [14:26]ALR:I got that ClassLoading SPI test passing
                                [14:27]kkhan:ok cool
                                [14:27]ALR:Let's see what events you need:
                                [14:27]kkhan:ALR: It probably makes sense to rever what I had done to get rid of all the deps
                                [14:27]kkhan:and then do it properly
                                [14:27]kkhan:so I didn't really look into the ClassLoading SPI test since that was more deps
                                [14:28]kkhan:I want something like PRE_KERNEL_BOOTSTRAP and POST_KERNEL_BOOTSTRAP
                                [14:29]kkhan:ALR: Sound ok?
                                [14:29]ALR:kkhan: Not really in its current form
                                [14:30]ALR:As "Kernel" is an MC construct
                                [14:30]ALR:And these LifecycleStates are in the main API
                                [14:30]kkhan:Actually, I probably don't need the PRE one that can be done whenever
                                [14:30]kkhan:i.e. early
                                [14:30]ALR:kkhan: "INSTANCIATED"
                                [14:30]ALR:Or maybe PRE_INIT
                                [14:31]ALR:And the "post", when exactly does that need to happen?
                                [14:31]kkhan:The post needs to happen after the kernel has been bootstrapped, but before anything else has been deployed
                                [14:32]ALR:kkhan: By "deployed", you mean processing the bootstrap XMLs?
                                [14:32]kkhan:yes
                                [14:32] pgier joined the chat room.
                                [14:32] pgier was granted voice by ChanServ.
                                [14:32]ALR:OK
                                [14:32]ALR:Lemme look
                                [14:33]kkhan:ALR: I think a PRE_CONFIG or POST_CONFIG state would do the trick, to be raised by AbstractServer.doInitialize() somewhere
                                [14:33]kkhan:That should be generic enough
                                [14:33]ALR:Yep
                                [14:33]kkhan:ALR: Ok, I'll go with that then
                                [14:34]ALR:Just need to think of a good name.
                                [14:34]ALR:I think "PRE_BOOTSTRAP", "POST_BOOTSTRAP"?
                                [14:34]kkhan:Hmm, not sure
                                [14:34] vblagoje joined the chat room.
                                [14:35]ALR:That's essentially what we're doing.
                                [14:35]kkhan:Since only AbtractMCServerBase calls bootstrap
                                [14:35]ALR:The generic API knows about bootstraps.
                                [14:35]kkhan:So where do I raise it?
                                [14:35]ALR:Yes, but that's only because it's our only impl.
                                [14:35]ALR:We could also, for instance, have a Fungal (JCA Kernel) implementation.
                                [14:36]ALR:So you'd fire the callbacks in AbstractMCServerBase, yes.
                                [14:36]ALR:Or at a higher level, even better, if you could refactor to get the right wiring.
                                [14:37]kkhan:I think I'd like to trigger it from AbstractServer.doInitialize()
                                [14:37]ALR:Yes, all you need to do is call "setState"
                                [14:37]kkhan:Just need the name
                                [14:38] smarlow is now known as smarlow_afk.
                                [14:38]ALR:AbstractServer.doInitialize is now abstract
                                [14:38]ALR:So again, some refactoring may be needed to get your pre/post bootstrap hooks up at that level
                                [14:38]ALR:kkhan: Why don't I take this?
                                [14:38]ALR:I'll get you the hooks.
                                [14:38]ALR:And refactor the events and the tests.
                                [14:38]kkhan:ALR: Cool
                                [14:38]ALR:Then you can extract out your ClassPool stuff.
                                [14:39]ALR:And reintegrate it.
                                [14:39]kkhan:ALR: Yeah, sounds good
                                [14:39]kkhan:Thanks
                                [14:39]ALR:kkhan: Where do you see the ClassPool logic going?
                                [14:39]kkhan:ALR: I think that will go in the classpool project
                                [14:40]kkhan:And then I'll modify AS MAin to set the correct event handlers before booting the server
                                [14:40]ALR:kkhan: Making ClassPool depend upon bootstrap-api?
                                [14:40]kkhan:ALR: I haven't looked too much into which deps that would bring in yet
                                [14:40]ALR:kkhan: I think we should put it into bootstrap-impl-as.
                                [14:41]ALR:kkhan: For 2 reasons:
                                [14:41]kkhan:ALR: ok by me
                                [14:41]ALR:1) ClassPool needn't know about Bootstrap.
                                [14:41]ALR:2) We shouldn't add the event handlers in AS Main; that's used only by standalone AS.  We get it for free in Embedded if we set it up in bootstrap-as.
                                [14:42]kkhan:ALR: ok, as long as you don;t mind the deps there.
                                [14:42]ALR:kkhan: Nope.  It's for AS, so all bets are off.
                                [14:42]kkhan:ALR: ok cool

                                 

                                • 13. Re: ClassPool bootstrap refactoring
                                  kabirkhan

                                  Kabir Khan wrote:

                                   

                                  I'll try to dig in to the errors tomorrow, although I am not sure how much time I will spend on this since we are only really targeting AS 6 with the current AOP releases, supporting previous AS versions is just us "being nice".

                                  I ran the tests. In AS 4 it is fine apart from

                                  I don't have time to look into this now. I am in the process of releasing AOP 2.2.1.Alpha1 and have raised https://jira.jboss.org/jira/browse/JBAOP-790 for 2.2.1.GA