Pretty much the tcl is set whenever a call enters into a container, be it jmx, ejb, web. Its needed when transitioning from the microkernel into a deployment context that can introduce new classes or class versions due to a deployment.
It would generally seem that the TCL is the more typical level at which you would want to associate aspects as at least the metadata is likely to be coming from the application context. I have been noticing some issues with using the TCL as a key due to the fact that we tend to have noop class loaders to differentiate deployment contexts, and it can be a little hard to control how certain searches for resources behave. Another thing that is difficult is cleaning up classes on redeployment. The java.lang.ClassLoader in at least sun's impl has a private array of the classes loaded that cannot be cleared by subclasses. What I'm seeing with extensive holders of the TCL is that its difficult to clear everything, and this can lead to the use of stale classes, and leaks when frameworks make use of caches keyed to class statics. Because there are a fair number of issues with the current class loading that cannot be changed, I'm thinking that we need to be looking at another thread context at the key rather than the thread context class loader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3831218#3831218 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3831218 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
