"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, and I think the KCC loader was ignored previously. Anyway, whatever was put in by the metadata did work. "adrian(a)jboss.org" wrote : | Asking the controller context essentially asks the ClassLoaderMetaData | if it has one (otherwise it uses the TCL), | which will be coming from whatever you setup in the deployer. | That is different from the ClassLoaderMetaData that is in GBF. Maybe not before I start messing around with things, but definitely after calling GBF.setClassLoader(). "adrian(a)jboss.org" wrote : | AbstractAopMetaDataDeployer | | | private void deploy(FakeComponentUnit unit, BeanMetaData deployment) throws DeploymentException | | { | | // No explicit classloader, use the deployment's classloader | | if (deployment.getClassLoader() == null) | | { | | try | | { | | // Check the unit has a classloader | | unit.getClassLoader(); | | // TODO clone the metadata? | | deployment.setClassLoader(new DeploymentClassLoaderMetaData(unit)); // HERE | | } | | catch (Exception e) | | { | | log.debug("Unable to retrieve classloader for deployment: " + unit.getName() + " reason=" + e.toString()); | | } | | } | | | Yes, that sets the correct classloader to use for the GenericBeanAspectFactory. But when needing to create an instance from a scoped classloader with no child delegation that also defines the class, that is the wrong loader (i.e. the parent). In all other cases this loader is fine. "adrian(a)jboss.org" wrote : | anonymous wrote : | | Rather than calling GBF directly from GBAF, if there is a pushed classloader I am trying to wrap GBF in a wrapper class that implements the same createBean() method, but with the option to specify the classloader. This gives me better results although I am still seeing some failures. | | The ClassLoaderMetaData is also used to decide the classloader for other things, | e.g. string conversion to classes so I don't think being able to specify a classloader | on the GBF method is much help without rewriting all the metadata classes to also | allow the classloader to be overridden. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193029#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...