Bean as a value to a deployment level classloader

[adrian.brock]

This test is failing because there is no "rewrite" of the ClassLoaderMetaData
to unwrap the embedded BeanMetaDataFactory.

java.lang.IllegalStateException: Bean not found cl at state ControllerState@120d62b{Installed}
 at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getControllerContext(MicrocontainerTestDelegate.java:152)
 at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.getBean(MicrocontainerTestDelegate.java:125)
 at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:93)
 at org.jboss.test.kernel.junit.MicrocontainerTest.getBean(MicrocontainerTest.java:80)
 at org.jboss.test.kernel.deployment.test.BeanMetaDataWithClassloaderTestCase.testBeanAsValueMetaData(BeanMetaDataWithClassloaderTestCase.java:48)

i.e. replace

 <classloader>
 <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" />
 </classloader>

with

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

 <bean name="cl" class="org.jboss.test.kernel.deployment.support.NullClassLoader" />

This needs to get done somewhere in AbstractKernelDeployer.deployBeans()
with deployBean() using any modified version.

We don't want to modify the ClassLoaderMetaData set on the deployment by the user!

[alesj]

We don't want to modify the ClassLoaderMetaData set on the deployment by the user!

I don't see what we are modifying in this case?
Probably nothing currently?
But we should add a dependency on the ClassLoaderMetaData in case actual classloader is inner bean.

[adrian.brock]

The other failing classloader test is due to the "mock" VFSClassLoader
getting used to load kernel classes causing a type inconsistency.

This is probably also due to the core kernel classes and the test classes
living in the same codesource with the current eclipse configuration.

I've hacked this classloader so it only loads classes that begin with "org.jboss.test"

 public Class<?> loadClass(String name, boolean flag)
 throws ClassNotFoundException
 {

+ if (name.startsWith("org.jboss.test") == false)
+ return getClass().getClassLoader().loadClass(name);

Which resolves this issue.

[adrian.brock]

"alesj" wrote:

We don't want to modify the ClassLoaderMetaData set on the deployment by the user!

I don't see what we are modifying in this case?

Your wrote the test case. :-)

Probably nothing currently?

Correct.

But we should add a dependency on the ClassLoaderMetaData in case actual classloader is inner bean.

We should clone and rewrite the ClassLoaderMetaData to replace the nested bean
with an injection and add the bean to the beans in the deployment.

[alesj]

We should clone and rewrite the ClassLoaderMetaData to replace the nested bean
with an injection and add the bean to the beans in the deployment.

Yup, this one is an oldie in my JIRA tasks. :-(
Along with inner beans with no name.
But this should all be done as a part of GUID naming rewrite you mentioned in our 'scoped' discussion: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=101320&start=20