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

kabir.khan@jboss.com do-not-reply at jboss.com
Fri Nov 28 08:59:59 EST 2008


"adrian at jboss.org" wrote : "kabir.khan at 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 at 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 at 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 at 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#4193029

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



More information about the jboss-dev-forums mailing list