10:02 a.m.
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
1:51 a.m.
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
2:01 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4623
days inactive
4624
days old
2 comments
3 participants
participants (3)
-
Jaikiran Pai -
Jason T. Greene -
Stuart Douglas