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

[Stuart Douglas]

No, this only sets the TCCL to the ClassLoader of the service or listener that MSC is starting/stopping/invoking. So if you have a MSC service from the EE subsystem, when it is started the TCCL will be the EE subsystem module class loader.

For DUP's that load classes you must still manually set the TCCL to the deployment class loader.

Stuart


On 30/08/2011, at 4:51 PM, Jaikiran Pai wrote:

> On Monday 29 August 2011 08:32 PM, Jason T. Greene wrote:
>> 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)
> 
> Does this also include DUPs which trigger the component class 
> instantiation? Last time I checked [1], there was an issue where a DUP 
> would trigger a class load of a user class, leading to the static block 
> of that user class being run and if that static block used JAXP API, it 
> would run into trouble due to null TCCL.
> 
> [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003337.html
> 
> -Jaikiran
>> 
>> 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
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev