[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: ClassLoader injection Scope issue

[alesj]

"adrian at jboss.org" wrote : My guess is that this has nothing to do with JBossAS?
  | There is nothing that I'm aware of in JBossAS that does anything different.
  | 
This example (see my initial post's top) is taken from my MC demos - as part of DZone articles:
 - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/

Afaik the example looks legit.
CB1 bean wants to use currently defined classloader (custom-classloader) as its classloader.

And as I explained, or at least tried to explain :-), 
the difference from JBossAS and this example is in how those files get deployed:

JBossAS; ServerImpl class:

  |       log.debug("BootstrapURLs=" + bootstrapURLs);
  |       
  |       // Create an xml deployer
  |       kernelDeployer = new BasicXMLDeployer(kernel);
  |       try
  |       {
  |          // Deploy the bootstrap urls
  |          for (String bootstrapURL : bootstrapURLs)
  |          {
  |             url = new URL(configURL, bootstrapURL);
  |             kernelDeployer.deploy(url);
  |          }
  |          
  |          // Check it is complete
  |          kernelDeployer.validate();
  | 
--> direct install into kernel --> no BeanMetaDataDeployer --> no scope merging

My example:
 - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/ioc/src/main/resources/META-INF/classloader-beans.xml
goes over BeanMDDeployer --> scope merging.
Scope merging requires CL to already be set - see previous post's exception.

And to my knowledge, no other -beans.xml in JBossAS uses
this classloader schema + setting this newly created cl as deployments cl,
except the files referenced in bootstrap.xml.

"adrian at jboss.org" wrote : 
  | To use the VFSClassLoaderFactory you need to have the 
  | ClassLoading/ClassLoaderSystem deployed first.
  | 
  | If you don't do this is a seperate deployment up-front
  | (see Common.xml in the classloading-vfs tests)
  | then you need to make sure these don't depend on the vfs classloader
  | you want to construct otherwise you'll get a "circular dependency".
  | 
  | See conf/classloader.xml in jboss.xml (note they are first with classloader==null)
  | 
I already have all of these.
My demos use simplified version of JBoss5 bootstrap.
See bootstrap and jmx sub-projects in demos project:
 - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/bootstrap/src/main/resources/META-INF/bootstrap-beans.xml
 - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/jmx/src/main/resources/META-INF/

"adrian at jboss.org" wrote : 
  | I quote "circular dependency" because it is not really a circular dependency,
  | what actually happens is that the classloader (which automatically has classloader=null)
  | gets re-ordered to be before the ClassLoading being deployed and so it won't get
  | registered using the incallback before you want to want to do
  | "ClassLoading".getClassLoader().
  | 
  | Or more schematically:
  | 1) deploy ClassLoading
  | 2) deploy ClassLoader
  | 3) ClassLoading depends on ClassLoader (because classloader != null)
  | 4) ClassLoading Module for ClassLoader is created but not registered with 
  | ClassLoading (no incallback  yet)
  | 5) Try Configurator.getBeanMetaData("ClassLoading") // ERROR it didn't go through the ClassLoading!
  | 6) If (5) worked then it would register the incallback for "ClassLoading"
  | and the ClassLoader would properly be constructed.
  | 
  | NOTE (5) could also be any request to get the classloader if its ClassLoadingModule
  | hasn't been registered with ClassLoading to resolve and create the classloader.
Is this all about how classloader.xml is eventually deployed/installed?
Since I don't see how it's related to my problem.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185109#4185109

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185109