[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Module.getModuleForClassLoader()

[adrian@jboss.org]

"kabir.khan at jboss.com" wrote : "adrian at jboss.org" wrote : 
  |   | What is different between that and using the bootstrap if you are asking the question
  |   | part way through the bootstrap process?
  |   | 
  | The Bootstrap implementations are invoked AFTER the bootstrap deployments are deployed, so all the classloaders have been created. AbstractServerImpl:
  | 
  |   |    public void start() throws IllegalStateException, Exception
  |   |    {
  |   |          ...
  |   |          // deploys conf/bootstrap.xml and conf/bootstrap/*.xml
  |   |          doStart(watch);
  |   | 
  |   |          // TODO Fix the TCL hack used here!
  |   |          ClassLoader cl = Thread.currentThread().getContextClassLoader();
  |   |          try
  |   |          {
  |   |             // Run the bootstraps
  |   |             for (Bootstrap bootstrap : bootstraps)
  |   |             {
  |   |                Thread.currentThread().setContextClassLoader(bootstrap.getClass().getClassLoader());
  |   |                startedBootstraps.add(0, bootstrap);
  |   |                bootstrap.start(this);
  |   |             }
  |   |          }
  |   |          finally
  |   |          {
  |   |             Thread.currentThread().setContextClassLoader(cl);
  |   |          }
  |   |          ...
  |   |    }
  |   | 
  | /quote]
  | 
  | Isn't that actually a bit late? I assume if the one of the bootstraps
  | wants to use aop you would need to know about the Module once it is installed
  | rather than the end of the bootstrap process?
  | i.e. the pojo deployment will try to load a class that needs to be weaved.
  | 
  | In practice, once all the boostraps have run, the server is fully deployed,
  | see for example ProfileServiceBootstrap.start()
  | so you would actually be looking at the end of the full server boot wouldn't you?
  | 
  | anonymous wrote : 
  |   | "adrian at jboss.org" wrote : 
  |   |   | Maybe a better mechanism would be to use the in/uncallback to be notified of the Modules
  |   |   | as they are constructed/destroyed. 
  |   |   | 
  |   | Why is that better? I'm happy with using bootstrap, as long as the following is ok:
  |   | - use KernelDeployment.getClassLoader() to get classloader name and look that up in MC
  |   | - use ClassLoading.getModuleForClassLoader() to get the module corresponding to the classloader rather than the findModule() stuff from my workaround example
  |   | 
  | 
  | It's better because you are not mixing policy and implementation.
  | 
  | But I'm what I'm really saying is that you are relying on one particular 
  | configuration/implementation of the bootstrap. 
  | 
  | Even the fact that the bootstrap is based on pojo deployments could change.
  | I know this is not likely but you are making integration assumptions around
  | implementation details which is always a bad plan.
  | 
  | Futher, there could be other pojo deployments that are not part of the bootstrap
  | but still create their own classloader/module.
  | 
  | anonymous wrote : 
  |   | If I have understood correctly, using a bootstrap I only need to modify aop.xml, making it easy to upgrade older versions of AS. Otherwise I need to modify classloader.xml to add the in/uncallback stuff. Will that work when the classes I need are in the aop classloader that has not been deployed yet? If I add the un/incallback in aop.xml, is that retroactive, i.e. will classloaders added previously in the bootstrap process (from classloader.xml) be added? 
  | 
  | No, you modify your pojo to have add/removeModule() methods
  | and then define the in/uncallback methods in your aop.xml for that bean.
  | 
  | You are then using the same mechanism as the ClassLoading uses to be notified
  | of what Modules are created "manually" (rather than through the deployers). 
  | So you are unlikely to have an inconsistent view. ;-)
  | 
  | This also makes your integration cleaner. 
  | You have some bean that just has add/removeModule() as your api. 
  | 
  | You then tell the MC to make the necessary calls.
  | 
  | If somebody really needs to do extra work in certain specifc cases, 
  | (e.g. they create a Module programmatically outside either the jboss-beans.xml or the deployers) it is possible for them to tell you about it using that simple api.

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

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