[adrian.brock]

Rather than the MC which just has a more direct "DO THIS" style metadata.

The only way I can see this working from the MC would be to have a strong
integration between the ClassLoader factory and the KernelController dependency model
such that the ClassLoader "repository" can restart deployments to resolve problems.

I think I prefer to have this at a higher level of abstraction.

[starksm64]

The ejb/war version 1.7/1.8 conflict is a different usecase from what I am talking about. It is one we want to deal with though.

I'm considering a self contained deployment (ear) consisting of an ejb/war that have expressed some class loader metadata such as the local class import/exports and the war has indicated it wants to use its classes before anything else (to the osgi module example, maybe directionality of class loading is the wrong approach, but configuring every library version is too complicated for the user). We have much expeirence with users throwing way too much garbage into wars to trust that they have done this correctly in terms of the interactions with other components, including the jboss containers themselves. The deployers want to augment the class loader configuration to deal with this. Most likely its the ear deployer introducing an aspect to control the ejb and war deployer class loader factories or the metadata they use.

[adrian.brock]

One way to do the strong integration without having a higher level abstraction
would be to have the classloaders become http://anoncvs.forge.jboss.com/viewrep/~raw,r=1.3/JBoss/microkernel/src/main/org/jboss/kernel/spi/dependency/KernelControllerContextAware.java

That way as new classloaders are injected into the repository the repository could
choose to restart some classloaders with new configuration and hence their
related deployments.
Using the controller context it has been passed.

<bean name="WARDeployment">
 <classloader><inject bean="WARCL"/>
</bean>

<bean name="WARCL">
 <install bean="EAR-CL-RESPOSITORY"/>
</bean>

Deploying this will cause the EAR-CL-REPOSITORY to restart the WARCL
and its related WARDeployment

<bean name="EJBDeployment">
 <classloader><inject bean="EJBCL"/>
</bean>

<bean name="EJBCL">
 <install bean="EAR-CL-RESPOSITORY"/>
</bean>

I leave to you how the repository/classloader knows when there is conflict
that needs resolving :-)

[adrian.brock]

Update: I've reworked the tests to also include the xml classloader definition.
The schema needs fixing see the FIXME in the xsd and also we need to do the beanfactory.

[adrian.brock]

Ok. But the current kernel tests don't really have a "deployment". The xml versions of
the test do.
These should probably be brought inline with the programmatic versions using
an AbstractKernelDeployment rather than deploying beans individually.

AbstractKernelDependencyTest
 protected ControllerContext install(int number, String name) throws Throwable
 {
 if (xmltest)
 {
 deploy(number);
 return util.getContext(name);
 }
 else
 {
 return util.install(beanMetaDatas[number]);
 }
 }

I can look at fixing this if you like?

Yes, that would be good as this discrepency is why I simply did not get into changing the KernelDeployment.

This is going to take more work than I thought and probably isn't worth doing?
The idea of the dependency tests was originally to test installation in the correct
order, wrong order and reinstallation. So I made the beanmetadatas and xml
deployments separate pieces such that they could be manipulated independently.

I'm going to create a different abstract testcase for deployment level tests
and controller tests that are not tweaking the dependency mechanism
(like the access control test).
This should be a simple extension to Abstract ConfigTest

[adrian.brock]

Update: I've done the deployment level classloader

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
 xmlns="urn:jboss:bean-deployer">

 <bean name="URL" class="java.net.URL">
 <constructor factoryClass="org.jboss.test.classloading.vfs.ClassLoaderUtil"
 factoryMethod="getLocation">
 <parameter>org.jboss.test.kernel.deployment.test.DeploymentClassLoaderTestCase</parameter>
 </constructor>
 </bean>

 <bean name="DeploymentClassLoader" class="org.jboss.test.classloading.vfs.VFSClassLoader">
 <constructor factoryClass="org.jboss.test.classloading.vfs.VFSClassLoaderFactory"
 factoryMethod="newClassLoader">
 <parameter><array><inject bean="URL"/></array></parameter>
 </constructor>
 </bean>

 <bean name="BeanClassLoader" class="org.jboss.test.classloading.vfs.VFSClassLoader">
 <constructor factoryClass="org.jboss.test.classloading.vfs.VFSClassLoaderFactory"
 factoryMethod="newClassLoader">
 <parameter><array><inject bean="URL"/></array></parameter>
 </constructor>
 </bean>

</deployment>

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
 xmlns="urn:jboss:bean-deployer">

 <classloader><inject bean="DeploymentClassLoader"/></classloader>

 <!-- USES THE CLASSLOADER FROM THIS DEPLOYMENT -->

 <bean name="DeploymentConfiguredClassLoader" class="org.jboss.test.kernel.deployment.support.SimpleBeanImpl">
 <property name="string">String1</property>
 </bean>

 <!-- USES A SPECIFIC CLASSLOADER -->

 <bean name="BeanConfiguredClassLoader" class="org.jboss.test.kernel.deployment.support.SimpleBeanImpl">
 <classloader><inject bean="BeanClassLoader"/></classloader>
 <property name="string">String1</property>
 </bean>

 <!-- USES THE DEPLOYER'S TCL -->

 <bean name="NotConfiguredClassLoader" class="org.jboss.test.kernel.deployment.support.SimpleBeanImpl">
 <classloader><null/></classloader>
 <property name="string">String1</property>
 </bean>

</deployment>

[adrian.brock]

You obviously don't need to set the classloader to null if you haven't configured
a deployment level classloader.

[adrian.brock]

Still to do.

* Tidyup the xml and SchemaBinding such that only reasonable ValueMetaData can be
inserted into the ClassLoaderMetaData
* Add ClassLoaderMetaData to the beanfactory.

[starksm64]

I'm going to create a different abstract testcase for deployment level tests
and controller tests that are not tweaking the dependency mechanism
(like the access control test).
This should be a simple extension to Abstract ConfigTest

Ok.

[adrian.brock]

Still to do.

* Tidyup the xml and SchemaBinding such that only reasonable ValueMetaData can be
inserted into the ClassLoaderMetaData
* Add ClassLoaderMetaData to the beanfactory.

While I'm using this thread as a TODO list of classloading. :-)

There is also this related issue that has classloader implications:
http://jira.jboss.com/jira/browse/JBMICROCONT-29

e.g. this FIXME in the code (note the use of the TCL):

 /**
 * Get the class info for the element type
 *
 * todo FIXME classloader
 * @return the class info
 * @throws Throwable for any error
 */
 protected ClassInfo getElementClassInfo() throws Throwable
 {
 if (elementType == null)
 return null;

 return configurator.getClassInfo(elementType, Thread.currentThread().getContextClassLoader());
 }

This is probably going to require this work:
http://jira.jboss.com/jira/browse/JBMICROCONT-25
that I've left outstanding since the ClassInfo rewrite such that the
ClassLoader is passed in the api.

[adrian.brock]

This work didn't have a JIRA task:
http://jira.jboss.com/jira/browse/JBMICROCONT-58