[jboss-dev-forums] [Design of POJO Server] - Re: Not keeping track of deployment class loader

&quot;scott.stark(a)jboss.org&quot; wrote : | On startup we have a hack in the ProfileServiceBootstrap to take the first bootstrap DeploymentContext as the base TCL. I suppose the ShutdownHook should be going through the profile service to shutdown the deployments in phases and employ the same hack, but shouldn't there be an association in the ControllerContext to the install action class loader if it came from the TCL rather than the BeanMetaData? | The TCL switching does not exist in the Microcontainer (like it does in JMX). I always believed this should be in an interceptor rather than in the "container" since it should be optional behaviour. In fact, this problem comes because of the HACK. What would really be required is to inject the classloader into the Profile Service Bootstrap deployment. | <deployment> | <classloader><inject bean="BootstrapClassLoader>/></classloader> | | <!-- More likely a factory! --> | <bean name="BootstrapClassLoader"> | <!-- Obviously we can't use ourselves so use the caller --> | <classloader><null/></classloader> | </bean> | | <!-- Other beans heres --> | | </deployment> | But that isn't easy to do with the current way the classloaders get constructed inside JMX. It would however be trivial to remember the TCL that created the kernel controller context (if there is nothing explicitly configured on the bean or deployment) and switch to it during the (un)install actions. This would be similar to the AccessControlContext code that restores the registering context's security context for callouts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009421#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...