0 Replies Latest reply on Jan 22, 2008 10:07 AM by Adrian Brock

    Finishing the OSGi classloading rules

    Adrian Brock Master

      Well not actually finishing, but at least completing the infrastructure
      so that our OSGi facade can plugin its requirements.

      Currently the module classloading system is in the deployment layer
      which as described in a related thread needs making independent of this.

      Inside the deployers, the module needs to be defined using a ClassLoaderMetaData
      (from the hypothetical META-INF/jboss-classloader.xml -
      not to be confused with the class of the same name in the MC).

      The only current ways to create a ClassLoaderMetaData to use the old
      LoaderRepositoryConfig for which we have a hack that maps to the new metadata
      or to create it programmatically.

      What needs doing is creating a parsing deployer for a META-INF/jboss-classloader.xml
      where you can define it more explicitly.

      Additionally the classloader metadata needs enhancing to make sure we have
      all the rules we need. Most of them are defined as Requirements (e.g. imports)
      or Capabilities (e.g. exports).

      This works fine for simple cases, but for OSGi cases like "uses" there
      needs to be additional consistency checks that makes sure that classloaders
      that can "see each other" are loading the same versions of classes that
      they pass between each other.

      Of course OSGi has additional fine grained rules like dependending on
      attributes of a deployment rather than a name/version, but that isn't very difficult
      and can be done in the OSGi facade.