2 Replies Latest reply on Jan 22, 2008 10:13 AM by adrian.brock

    Using the new classloader in the bootstrap

    adrian.brock Jan 22, 2008 9:53 AM

      As discussed previously, the bootstrap really needs to be modularised.

      Currently it does multiple tasks using two different bootstrap files
      conf/bootstrap-beans.xml and conf/jboss-service.xml

      The base classloader is "hardwired"

       <bean name="BootstrapClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader">

 <classloader><null/></classloader>

 <constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader">

 <parameter>

 <array elementClass="java.net.URL">

 <!-- VFS -->

 <value>${jboss.lib.url}/jboss-vfs.jar</value>

 <!-- ClassLoader -->

 <value>${jboss.lib.url}/jboss-classloading-spi.jar</value>

 <value>${jboss.lib.url}/jboss-classloader.jar</value>

 <value>${jboss.lib.url}/osgi.core.jar</value>

 <!-- Deployers -->

 <value>${jboss.lib.url}/jboss-metatype.jar</value>

 <value>${jboss.lib.url}/jboss-managed.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-core-spi.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-core.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-client-spi.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-client.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-structure-spi.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-spi.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-impl.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</value>

 <value>${jboss.lib.url}/jboss-deployers-vfs.jar</value>

 <!-- System -->

 <value>${jboss.lib.url}/jboss-system.jar</value>
etc.


      The proposal is to split the bootstrap into multiple files such that
      it is easier to confgure, understand and replace part of the implementation.
      i.e. make it more modular

      One example would be able to swap out the profile service implementation
      by just replacing one file, instead of having to copy and maintain
      all the other configuration that is largely orthogonal.

      This would use the new classloader with something like
      (using the use case xml to make it look like the proposed META-INF/jboss-classloader.xml - see related thread): 
      <deployment xmlns="urn:jboss:bean-deployer:2.0">


 <classloader xmlns="urn:jboss:classloader:1.0"
 name="jmx-kernel"
 version="5.0.0.GA"
 >
 <!-- old rules -->
 <export-all/>
 <import-all/>

 <!-- or export specific packages -->
 <export package="org.jboss.mx"/>
 <export package="org.jboss.mx.server"/>

 <!-- or osgi style imports -->
 <import module="log4j" version="[1.2.3,2.0.0)"/>
 <import package="org.jboss.system"/>

 <classpath>${jboss.lib.url}/jboss-system-jmx.jar</classpath>
 <classpath> ${jboss.lib.url}/jboss-jmx.jar</classpath>
 <etc./>
 </classloader>


      This requires the implementation of this task:
      http://jira.jboss.com/jira/browse/JBOSGI-15
      but it also requires change the module abstraction to not depend upon
      the deployment layer:
      http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontainer/trunk/deployers-impl/src/main/org/jboss/deployers/plugins/classloading/Module.java?revision=66296&view=markup
      i.e. make it an interface that can implemented from POJO or Deployment layer metadata
      when asking for the "ClassLoaderMetaData".

      I believe Ales is working on changes in this currently to remove the
      dependency on OSGi dependency of the Version implementation.

      • 2181 Views
      • Tags: