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.
