[jboss-dev-forums] [Design the new POJO MicroContainer] - Using the new classloader in the bootstrap

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/microcontaine... 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122233#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...