[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk

"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote : | | | Some code in GenericBeanAspectFactory.doCreate() handled that scenario and pushed the correct loader to use into the underlying GenericBeanFactory. | | | | | How did this work? I don't see anything in the previous GBF code that allowed you | | to override the classloader (other than the metadata). | | | The "pushed" metadata was the mechanism. For some reason the GBF.getClassLoader() always returned null, I think this is the real change isn't it? It would depend upon how you created/deployed the GBF's metadata. How old is the previous code I showed? anonymous wrote : | and I think the KCC loader was ignored previously. Anyway, whatever was put in by the metadata did work. | This is the code from 7 months ago before recent changes. You can see it looks at the context first http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... But actually looking at the logic behind all this, I don't see why we need to look at the context for classloader since the next step is to ask the ClassLoaderMetaData anyway (or use the TCL absent that). | private Object createBean(ClassLoader cl) throws Throwable | { | ClassLoader loader = cl; | if (loader == null) | loader = Configurator.getClassLoader(classLoader); | For everybody else, this will be same as asking the controller context since the "classLoader" above is the same ClassLoaderMetaData. But for you who wants to change the logic, it will do something different. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193035#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...