-
30. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 7, 2005 5:42 PM (in response to starksm64)
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. -
31. Re: Change DomainClassLoader getPackages signature
starksm64 Nov 7, 2005 5:59 PM (in response to 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. -
32. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 7, 2005 6:10 PM (in response to starksm64)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 :-) -
33. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 7, 2005 8:50 PM (in response to starksm64)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. -
34. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 7, 2005 9:04 PM (in response to starksm64)"adrian@jboss.org" wrote:
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 -
35. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 8, 2005 5:24 PM (in response to starksm64)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>
-
36. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 8, 2005 5:25 PM (in response to starksm64)You obviously don't need to set the classloader to null if you haven't configured
a deployment level classloader. -
37. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 8, 2005 5:27 PM (in response to starksm64)Still to do.
* Tidyup the xml and SchemaBinding such that only reasonable ValueMetaData can be
inserted into the ClassLoaderMetaData
* Add ClassLoaderMetaData to the beanfactory. -
38. Re: Change DomainClassLoader getPackages signature
starksm64 Nov 10, 2005 3:18 PM (in response to starksm64)"adrian@jboss.org" wrote:
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. -
39. Re: Change DomainClassLoader getPackages signature
adrian.brock Nov 10, 2005 3:32 PM (in response to starksm64)"adrian@jboss.org" wrote:
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. -
40. Re: Change DomainClassLoader getPackages signature
adrian.brock Jan 21, 2006 7:25 AM (in response to starksm64)This work didn't have a JIRA task:
http://jira.jboss.com/jira/browse/JBMICROCONT-58