14 Replies Latest reply on Sep 25, 2008 9:37 AM by Kabir Khan

    Modularising the appserver bootstrap

    Adrian Brock Master

      WRT: https://jira.jboss.org/jira/browse/JBAS-5535

      I never really followed up on this, but the reason why this issue has stalled
      is because AOP is introducing a ciruclar dependency in the bootstrap.

      AspectManager -> scoping policy -> deployment unit -> main deployer -> jmx -> aop (via @JMX)

      This means we can't properly setup the bootstrap classloaders to be modular,
      see the FIXMEs in conf/classloader.xml

       <classloader name="bootstrap-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
       <!-- FIXME Move to Deployers -->
       <root>${jboss.lib.url}/jboss-deployers-core-spi.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-core.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-client-spi.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-client.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-structure-spi.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-spi.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-impl.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</root>
       <root>${jboss.lib.url}/jboss-deployers-vfs.jar</root>
       <!-- System -->
       <root>${jboss.lib.url}/jboss-system.jar</root>
       <!-- FIXME Move to JMX -->
       <root>${jboss.lib.url}/jboss-j2se.jar</root>
       <root>${jboss.lib.url}/jboss-mbeans.jar</root>
       <root>${jboss.lib.url}/jboss-jmx.jar</root>
       <root>${jboss.lib.url}/jboss-system-jmx.jar</root>
       <root>${jboss.lib.url}/dom4j.jar</root>
       <!-- JAXB impl here, api is in endorsed -->
       <root>${jboss.lib.url}/jaxb-impl.jar</root>
       <!-- STAX2 impl here, api is in endorsed -->
       <root>${jboss.lib.url}/wstx.jar</root>
       </classloader>
      


      The fix would to refactor the VFSClassLoaderScopingPolicy
      such that the deployment logic is in the deployers which just invoke the
      registerClassLoader()

      i.e. remove its dependency on the deployment layer

      That way we can bootstrap the AspectManager before the deployers and JMX
      are even loaded and it becomes independent of this implementation detail.

        • 1. Re: Modularising the appserver bootstrap
          Adrian Brock Master

           

          "adrian@jboss.org" wrote:

          The fix would to refactor the VFSClassLoaderScopingPolicy
          such that the deployment logic is in the deployers which just invoke the
          registerClassLoader()

          i.e. remove its dependency on the deployment layer


          Additionally, I think the logic in this code is a bit dated?

          With the new classloader, it is not just wars that can have their own isolated classloaders.
          Any subdeployment with its own classloading metadata can create a sub-module
          in its own classloader domain.

          And even wars don't necessarily have an isolated classloader, this is just a default rule,
          i.e. we add a classloading metadata to all wars that don't have an explicit one
          to put them in their own classloader domain.

          • 2. Re: Modularising the appserver bootstrap
            Adrian Brock Master

            I think there's also a dependency with the AspectManager bean expecting
            ServiceMBeanSupport to be available.

            But JMX deployment should come after AOP.

            The eventual idea is to make JMX optional.

            • 4. Re: Modularising the appserver bootstrap
              Adrian Brock Master

              Well don't forget that trunk is currently under a freeze. ;-)

              • 5. Re: Modularising the appserver bootstrap
                Kabir Khan Master

                Ah yes, thanks for reminding me :-)

                • 6. Re: Modularising the appserver bootstrap
                  Kabir Khan Master

                   

                  "adrian@jboss.org" wrote:
                  I think there's also a dependency with the AspectManager bean expecting
                  ServiceMBeanSupport to be available.

                  But JMX deployment should come after AOP.

                  The eventual idea is to make JMX optional.


                  I am putting the original AspectManagerService code in a delegate and wrapping that in a POJO (MC/AS5) and in a class extending ServiceMBeanSupport (AS4). However, the original code contains a few methods to do with JMX from ServiceMBeanSupport such as sending out JMX notifications, getting the ObjectName of the service, getting the MBeanServer etc. Can all that stuff be left out for the MC/AS5 version? I am not really clear on how the MC beans eventually get mapped onto JMX in AS5.

                  • 7. Re: Modularising the appserver bootstrap
                    Kabir Khan Master

                    These are some of the ServiceMBean-/JBossNotificationBroadcasterSupport methods.

                     public void addNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback)
                     public void removeNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback) throws ListenerNotFoundException
                     public void removeNotificationListener(NotificationListener listener) throws ListenerNotFoundException
                     public DeploymentInfo getDeploymentInfo() throws JMException
                     public MBeanNotificationInfo[] getNotificationInfo()
                     public MBeanServer getServer()
                     public ObjectName getServiceName()
                     public int getState()
                     public String getStateString()
                     public void jbossInternalLifecycle(String method) throws Exception
                     public void postDeregister()
                     public void preDeregister() throws Exception
                     public ObjectName preRegister(MBeanServer server, ObjectName name) throws Exception
                    

                    The only ones I seem to be using are these:
                     public void sendNotification(Notification notification)
                     public long nextNotificationSequenceNumber()
                     public void postRegister(Boolean registrationDone)
                    

                    From the previous code it seems that things like postRegister() will get called for an MC bean in AS. But how to implement the following for an MC bean?
                     public void addNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback)
                     public void removeNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback) throws ListenerNotFoundException
                     public void removeNotificationListener(NotificationListener listener) throws ListenerNotFoundException
                     public DeploymentInfo getDeploymentInfo() throws JMException
                     public MBeanNotificationInfo[] getNotificationInfo()
                     public MBeanServer getServer()
                     public ObjectName getServiceName()
                     public int getState()
                     public String getStateString()
                     public void jbossInternalLifecycle(String method) throws Exception
                    

                    Are they required at all?

                    • 8. Re: Modularising the appserver bootstrap
                      Kabir Khan Master

                      I've looked into it properly and reminded myself how this works :-) if running in AS5, I use an MC bean, which should not care about any of the extra JMX stuff. Since we want the AspectManager to be available in JMX (mainly for the testsuite) and the @JMX stuff is not available, I register a JMX MBean in JMX, and that will bother with all the extra JMX things.

                      • 9. Re: Modularising the appserver bootstrap
                        Carlo de Wolf Master

                        The removal of the aspect deployers from a separate component is not acceptable from EJB3 embedded perspective. Embedded should have any dependency on JBoss AS or its release cycle.

                        Either the deployers should be put back into the CR (!) / GA release, or a new component has to be formed which allows usage by EJB3 Embedded, JBoss Embedded and possibly Web Platform (or any other).

                        • 10. Re: Modularising the appserver bootstrap
                          Kabir Khan Master

                          I see your point. Let's see what Adrian says, since it was he who originally asked me to move classpool and deployers into the AS codebase.

                          Reverting this would mean moving some classes back out of AS into AOP or duplicating them in AOP. Having a separate component effectively just means the same as that, with yet another dependency to manage.

                          The classes in question are:
                          org.jboss.aop.asintegration.jboss5.AspectDeployer
                          org.jboss.aop.asintegration.jboss5.VFSClassLoaderDomainRegistry
                          org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain
                          org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy

                          • 11. Re: Modularising the appserver bootstrap
                            Adrian Brock Master

                             

                            "kabir.khan@jboss.com" wrote:
                            I see your point. Let's see what Adrian says, since it was he who originally asked me to move classpool and deployers into the AS codebase.

                            Reverting this would mean moving some classes back out of AS into AOP or duplicating them in AOP. Having a separate component effectively just means the same as that, with yet another dependency to manage.

                            The classes in question are:
                            org.jboss.aop.asintegration.jboss5.AspectDeployer
                            org.jboss.aop.asintegration.jboss5.VFSClassLoaderDomainRegistry
                            org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain
                            org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy


                            So are these JBoss specific or not?

                            If this is appserver integration then it belongs in the appserver.

                            If this is some other integration, e.g. deployers-aop
                            then I wouldn't have a problem with them living at that level as a separate project.

                            As long as you are not creating a circular dependency (either really or in the
                            release process).

                            That doesn't mean the appserver has to use those specifc classes.

                            Ideally, these classes should be very thin anyway. i.e. the implementation
                            is in the aop project using agnostic policy metadata,
                            but the specific population of the policy choices is in the deployers.

                            I think you already fixed some of this already with the latest changes to
                            remove the deployment api dependency from the class pool.

                            • 12. Re: Modularising the appserver bootstrap
                              Kabir Khan Master

                               

                              "adrian@jboss.org" wrote:

                              So are these JBoss specific or not?

                              They have dependencies on:
                              jboss-cl
                              jboss-deployers
                              jboss-vfs

                              So, I think the answer is "no" :-) AspectDeployer will be retired in AS when I switch to the MC based aop deployers (hopefully later this week).

                              "adrian@jboss.org" wrote:

                              I think you already fixed some of this already with the latest changes to
                              remove the deployment api dependency from the class pool.

                              Yes, second step is to get rid of the ServiceMBeanSupport dependency. I have that ready locally, but I need to do another aop release before I can add that.

                              • 13. Re: Modularising the appserver bootstrap
                                Kabir Khan Master

                                I will have a play and try to break up the asintegration module into
                                *asintegration-core - agnostic about the environment
                                *asintegration-jmx - The JMX service mbean wrapper, and the current JBoss 4 classpools etc.
                                *asintegration-mc - The MC service bean wrapper, and the current JBoss5 classpools etc.

                                Once this takes shape, I will probably also move the RepositoryClassLoader and VFSClassLoader based classpools and policies out into separate modules.

                                I will put in an AspectDeployer for use in JBoss embedded back as requested by Carlo, but for JBoss 5 leave the "real" deployers in AS.