4 Replies Latest reply on Mar 17, 2008 4:18 PM by Ales Justin

    State of the integration of the latest MC into AS

    Adrian Brock Master

      I've got jboss-head (not with the latest maven stuff) booting with the latest MC code.

      The changes fall into the following categories (ignoring changes to build.xml/.classpath)

      * Updates to use the classloading spi
      * ClassLoaderFactory now uses DeploymentUnit rather than DeploymentContext
      * ControllerMode is now an Enum rather than an interface with constants
      * Removal of some hacks (and a temporary introduction of another - see below ;-)
      * Removal of generics on MetaType/Value in the profile service

      Here's the artifacts effected in case you are working on one of these areas:

      [ejort@warjort jboss-head]$ svn status
      M system-jmx/.classpathM system-jmx/src/tests/org/jboss/test/system/deployers/support/CLDeployer.java
      M system-jmx/src/main/org/jboss/system/metadata/ServiceMetaDataParser.java
      M system-jmx/src/main/org/jboss/system/server/jmx/JMXKernel.java
      M system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java
      M system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java
      M system-jmx/src/main/org/jboss/system/microcontainer/jmx/ServiceControllerLifecycleCallback.java
      M system-jmx/build.xml
      M deployment/build.xml
      M profileservice/src/main/org/jboss/profileservice/management/ManagementViewImpl.java
      M profileservice/src/main/org/jboss/managed/plugins/factory/AbstractInstanceClassFactory.java
      M profileservice/build.xml
      M cluster/src/main/org/jboss/ha/jmx/HAServiceMBeanSupport.java
      M ejb3/build.xml
      M system/.classpath
      M system/src/main/org/jboss/aop/deployers/temp/Hack.java
      M system/src/main/org/jboss/system/server/profileservice/ProfileServiceBootstrap.java
      M system/build.xml
      M tomcat/src/main/org/jboss/web/tomcat/service/deployers/WarClassLoaderDeployer.java
      M spring-int/src/main/org/jboss/spring/deployers/SpringParserDeployer.java
      M spring-int/build.xml
      M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellDeployer.java
      M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellScriptDeployer.java
      M varia/build.xml
      M j2se/.classpath
      M server/src/etc/conf/default/bootstrap-beans.xml
      M server/build.xml
      M bootstrap/.classpath
      M bootstrap/build.xml
      M messaging/build.xml
      M webservices/src/main/org/jboss/wsf/container/jboss50/DynamicEndpointDeploymentAspect.java
      M webservices/build.xml
      M main/src/main/org/jboss/system/server/ServerLoader.java
      M embedded/src/main/java/org/jboss/embedded/ClassLoaderDeployer.java
      M embedded/.classpath
      M testsuite/src/main/org/jboss/test/deployers/seam/test/SeamVFSClassloadingTestCase.java
      M testsuite/build.xml
      M connector/build.xml
      M build/build-distr.xml
      M build/build-thirdparty.xml
      M aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderDomainRegistry.java
      M aspects/src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java
      M aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderScopingPolicy.java
      M aspects/src/main/org/jboss/aspects/security/SecurityDomain.java
      


      The work still do is what I expected (although a bit more in some parts)

      WEB CLASSLOADER

      The way this is currently implemented is conflicting with the infrastructure
      I've put in place to do this properly.
      I can get the server to boot without the WARClassLoaderDeployer stuff
      but obviously there's no scoping of wars.

      I'm going to work on integration the new mechanism properly next
      (well after I've synched with the maven build :-)

      MODULARISATION OF BOOTSTRAP

      There's a number of issues here, I'll deal with this on a different thread later.

      For now I've gone with the strategy of removing all the hacks and moving
      some jars back into ServerLoader (i,.e. the opposite of modularisation :-).
      This required the introduction of one new hack
      (setting the correct parent classloader on the default domain),
       // FIXME
       ClassLoaderDomain defaultDomain = system.getDefaultDomain();
       defaultDomain.setParent(new ClassLoaderToLoaderAdapter(getClass().getClassLoader()));
       mbeanServer.registerMBean(system, new ObjectName("jboss.classloader:service=ClassLoaderSystem"));
      

      but I can live with that until I do the modularisation properly.

      AOP INTEGRATION

      The temporary reversal of modularisation, i.e. moving some aop jars
      into ServerLoader has resolved the @JMX issue for now.

      But the major issue is that I haven't tested the changes to make
      aop's as integration use the org.jboss.classloading.spi.dependency classes
      rather than the old private classes from the deployers.

      OTHERS

      There's a couple of other minor issues I'm aware of, but these can
      be easily fixed.

      * @JMX is not registering the mbean with the correct classloader
      so invocations on the MBean use the wrong thread context classloader

      * The current way I am doing package scanning is not ignoring subdeployment
      roots correctly, e.g.

      /root.ear
      /root.ear/sub.jar
      /root.ear/sub.jar/com/acme/MyClass.class

      will create a package called com.acme as expected but also one called
      sub.jar.com.acme ;-)

      TIDY UP

      There's a fair amount of tidyup work to do as well
      but the modularisation work is probably when I'll do this.

      NEXT STEPS

      1) Make this work with the new maven build
      2) Replace the WarClassLoaderDeployer with the new subdeployment
      classloader mechanism
      3) Make sure AOP is still working
      4) Standup tests and fix problems (like the OTHERS raised above)
      5) Commit it (with fair warning first :-)
      6) Do the modularisation work (to be discussed)
      7) Work towards getting proper RC1/GA releases of the MC artifacts
      e.g. fixing/refactoring the deployers and closing all the JIRA issues in the MC

        • 1. Re: State of the integration of the latest MC into AS
          Adrian Brock Master

          I've decided to commit this, even though it is not complete.

          Trying to unravel how the WAR classloader is integrated (wrongly :-)
          is going to take me a fair bit of work in different places.

          For now I've just replaced the WARClassLoaderDeployer with a POST_PARSE
          deployer that creates the ClassLoadingMetaData for the war classloader.

          i.e. it uses the new mechanism but almost certainly with lots of problems that
          the old mechanism had.

          I'm also going to commit against the snapshot-temp I created of the MC.
          It will include an update JBossXB CR7

          This isn't ideal, but with Ales's latest change to add support for private
          field injection, despite my request NOT to do major changes until I'd updated the latest
          (split up) MC in to JBossAS
          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130461
          I don't feel confident about putting the latest stuff in there.

          We'd need to get this stablised as ASAP so we are back on proper releases
          and get to the CR1 as soon as possible.

          Reflection and MDR which is what Ales is changing are the only projects
          I'd done beta11 releases for, but they are obviously out-of-date now. ;-(

          • 2. Re: State of the integration of the latest MC into AS
            Ales Justin Master

             

            "adrian@jboss.org" wrote:

            This isn't ideal, but with Ales's latest change to add support for private
            field injection, despite my request NOT to do major changes until I'd updated the latest
            (split up) MC in to JBossAS
            http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130461
            I don't feel confident about putting the latest stuff in there.

            Reflection and MDR which is what Ales is changing are the only projects
            I'd done beta11 releases for, but they are obviously out-of-date now. ;-(

            My changes don't affect the previous code, at least that's what the tests said. :-)
            And it can also be a proof by design, since the only way you're gonna use the new changes is by triggering them using the new changes/additions to the API.
            And the changes in the Reflection have just one 'entry point', and that's the BeanAccessMode enum.
            The MDR changes are bug fixes. Which should be there anyway. ;-)

            • 3. Re: State of the integration of the latest MC into AS
              Adrian Brock Master

               

              "alesj" wrote:
              "adrian@jboss.org" wrote:

              This isn't ideal, but with Ales's latest change to add support for private
              field injection, despite my request NOT to do major changes until I'd updated the latest
              (split up) MC in to JBossAS
              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130461
              I don't feel confident about putting the latest stuff in there.

              Reflection and MDR which is what Ales is changing are the only projects
              I'd done beta11 releases for, but they are obviously out-of-date now. ;-(

              My changes don't affect the previous code, at least that's what the tests said. :-)


              I don't care what the tests said. I've spent the best part of the last two weeks
              doing "releases" of the latest MC code fixing problems while
              I try to split it up and integrate the latest stuff into JBossAS and test it.

              All that work would now be out of the window because of this fundamental change
              which isn't tested enough for me for me to take at the moment.

              Let's get it to a proper state this week then we can do proper releases
              all the way through the MC dependencies.

              The alternative, is to revert the changes in the kernel project so I can
              do a proper MC release off what I've tested (using beta11 of reflection/mdr).

              • 4. Re: State of the integration of the latest MC into AS
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:

                Let's get it to a proper state this week then we can do proper releases
                all the way through the MC dependencies.

                The alternative, is to revert the changes in the kernel project so I can
                do a proper MC release off what I've tested (using beta11 of reflection/mdr).

                OK, I'll still target Wednesday, in the worst case Thursday.
                And in the super worst case the revert will kick in. :-(