3 Replies Latest reply on Feb 18, 2008 4:20 PM by Adrian Brock

    New ClassLoadING projects in MC trunk

    Adrian Brock Master


      I've added the refactored classloadING projects to the MC trunk.

      There are two projects, one is the basic infrastructure "classloading'
      the other is the VFS plugin, including the BeanMetaDataFactory that can be
      used to create an OSGi style classloader in a -beans.xml

      This api is mainly taken from the deployers-impl/vfs projects and made into
      a public spi with a lot more tests and a few more features.

      There's the old issue with the VFS not working properly in Maven
      for the classloading-vfs tests. I'll take this up in the build forum.

      What's left to do?

      TODO OSGi

      In terms of for OSGi this method sums up what is left in the resolution process

       * Resolve the requirement
       * @param controller the controller
       * @param module the module
       * @param requirement the requirement
       * @return the resolved name or null if not resolved
       protected Object resolve(Controller controller, Module module, Requirement requirement)
       // TODO JBMICROCONT-182 include parent domains in requirements
       // TODO JBMICROCONT-182 check consistency of re-exports
       // TODO JBMICROCONT-182 check for self-dependency
       // TODO JBMICROCONT-182 test circularity
       for (Module other : modules)
       List<Capability> capabilities = other.getCapabilities();
       if (capabilities != null)
       for (Capability capability : capabilities)
       if (capability.resolves(module, requirement))
       return other.getContextName();
       return null;

      Basically instead of it resolving the capabilities based on list traversal
      over the modules and requirements, it needs to look at requirements
      in the round and try to resolve a consistent set for related classloaders.
      This includes classloaders from different domains.

      I pretty much know how to do this (there a few gotchas :-)
      but this only requires changes to implementation details.

      If you look at the code there's now support for re-exports and "uses"
      so the other remaining detail for OSGi are the dynamic imports.
      This may require a change to the ClassLoaderPolicy to make it work


      Going beyond OSGi, the next step is to plugin this work to the deployers.
      This should be fairly easy and the TopLevelClassLoaderDeployer should
      get a bit nicer.

      The only issue I can think are there a couple of places in the AS
      using the old private version of this api. These will obviously benefit
      from using a supported stable spi.

      TODO JBossAS RC1

      After that, the remaining classloader issues are:
      * Use the classloader-vfs to modularise the AS bootstrap
      * Add the management requirements that Scott asked for
      * Sort out the WAR classloader properly, i.e. introduce proper support
      in the deployers for subdeployments having managed child classloaders
      of the main deployment classloader.

      Once these issues are resolved, all the classloading requirements
      for JBoss5 and OSGi will be done. Other classloading changes
      should be just value add.