1 Reply Latest reply on Jul 17, 2006 10:26 AM by Adrian Brock

    ClassLoadingDeployer behavior

    Scott Stark Master

      One issue I'm seeing with implementing a class loading deployer that would handle issues such a manifest Class-Paths, OSGI bundle headers, some custom class loader metadata is that this would conflict with a class loader specified at the bean deployer level. For example,

      <!-- A beans descriptor -->
      <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"
       xmlns="urn:jboss:bean-deployer:2.0">
       <bean name="VFSClassLoader" class="org.jboss.vfs.classloading.VFSClassLoader">
       <constructor factoryClass="org.jboss.vfs.classloading.VFSClassLoaderFactory"
       factoryMethod="newClassLoader">
       <parameter>${jbosstest.deploy.dir}</parameter>
       <parameter>
       <array class="[Ljava.lang.String;" elementClass="java.lang.String">
       <value>org.jboss.server.support.jar</value>
       </array>
       </parameter>
       <parameter><inject bean="MainDeployer" property="VFSFactory"/></parameter>
       </constructor>
       </bean>
       <bean name="TestBean" class="org.jboss.test.server.support.TestBeanImpl">
       <classloader><inject bean="VFSClassLoader"/></classloader>
       <property name="intProperty">1234</property>
       <property name="integerProperty">4321</property>
       <property name="stringProperty">string-x</property>
       </bean>
      </deployment>
      


      I guess that the BeanDeployer could indicate that beans were seen with ClassLoaderMetaData, but it still would not be know if this was an override, or a class loader that should be augmented with deployment manifest settings.

      About the only thing I can think to do is have the ClassLoadingDeployer be responsible for the deployment context class loader, and the BeanDeployer could create a child class loader for any bean deployment local class loader.


        • 1. Re: ClassLoadingDeployer behavior
          Adrian Brock Master

          The purpose of this feature is to just to allow classloaders to take
          part in the dependency mechanism.

          e.g. I would expect you to use this to "inject" the classloader bean
          at the deployment level, make the whole deployment "depend" upon
          the classloader.

          If people want to write their own classloader beans then it is upto
          them to make them work correctly. :-)