[jboss-as7-dev] IMPORTANT TCCL & JAXP Changes!

Jason T. Greene jason.greene at redhat.com
Mon Aug 29 11:02:37 EDT 2011


Hello Everyone,

While we still want to avoid using TCCL for anything but interacting 
with thirdparty components or the SDK [1], there are some changes that 
have been made to the current master that make it easier to work with.

To discourage use in AS, and prevent the wrong classloader from ever 
being used, in many contexts (e.g. service lifeycle methods) we used to 
null the TCCL. Unfortunately due to (yet another) bug in various JAXP 
API implementations, a null TCCL, would trigger this problem:
https://issues.jboss.org/browse/AS7-1630

It also made using JAXP from a service or a management operation a 
little unwieldy since you had to push/pop TCCL yourself, as decribed in [1].

To address these issues we now ALWAYS set TCCL to the defining 
classloader of the component in the following cases:

- MSC Service lifecycle (start, stop)
- Listener callbacks
- MSC Lifecycle Context Execution Tasks
- Operation Handler invocations (includes all subsystem logic)

What does this mean to you?

1. If you are writing code that is executing in a service or as part of 
your subsystem you no longer need to worry about setting the TCCL, it 
will be set to your module classloader for you. You can therefore use 
JAXP or any other service loader style framework without worrying about 
this.

2. If you are writing code that is executed on behalf of an EE request, 
then TCCL will STILL point to the spec required deployment classloader. 
You MUST still push/pop the TCCL as described in [1] when using JAXP or 
any other service loader framework.

If you have any questions about this, feel free to ping me about it.

[1] http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


More information about the jboss-as7-dev mailing list