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

"adrian(a)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/trun... 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(a)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/trun... - http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trun... "adrian(a)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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...