"scott.stark(a)jboss.org" 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...