You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Davanum Srinivas <da...@gmail.com> on 2005/10/29 19:11:46 UTC
TCCL in doStart
Team,
I was trying GBean-izing some code that needed a stax parser (Axis2).
The FactoryFinder would not pick up the parser though it was specified
in the dependencies and present in the repository.
DJ mentioned that this is because the TCCL is set to the
configurations' classloader. So i had to forcibly set the context
class loader myself. I see the same hack in other places for example
in doStart method of
servicemix\src\java\org\apache\geronimo\servicemix\ServiceMixDeployment.java
So, Do we fix it? how? Should we fix it?
thanks,
dims
--
Davanum Srinivas : http://wso2.com/blogs/
Re: TCCL in doStart
Posted by David Jencks <da...@yahoo.com>.
On Oct 29, 2005, at 11:34 AM, Davanum Srinivas wrote:
> here's a log snippet from my GBean's doStart:
>
> 14:31:15,843 INFO [AxisHTTPBean] TCCL
> :sun.misc.Launcher$AppClassLoader@53ba3d
> 14:31:15,843 INFO [AxisHTTPBean] GBean ClassLoader:
> [org.apache.geronimo.kernel.config.MultiParentClassLoader
> id=org/apache/axis2]
>
> Please note that i don't have the addAttribute with "classLoader" in
> my GBEAN_INFO like all the other gbeans. (since i did not know how to
> create the GBean programatically with a class loader and load it into
> the kernel in my junit test case)
You create the gbeanInfo, set the attributes you know about, and the
kernel will take care of setting the magic classLoader attribute for
you. Be sure to declare the classLoader attribute non-persistent.
david jencks
>
> thanks,
> dims
>
> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>> Now I'm confused. I thought these would be the exact same
>> classloader. I thought there would only be one. Maybe David Jencks
>> can help here.
>>
>> -dain
>>
>> On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
>>
>>> The class loader that loaded the GBean. Sorry, i forgot to mention
>>> that.
>>>
>>> thanks,
>>> dims
>>>
>>> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>>>
>>>> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>>>>
>>>>
>>>>> DJ mentioned that this is because the TCCL is set to the
>>>>> configurations' classloader. So i had to forcibly set the context
>>>>> class loader myself.
>>>>>
>>>>
>>>> What did you forcibly set it to?
>>>>
>>>> -dain
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas : http://wso2.com/blogs/
>>>
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: TCCL in doStart
Posted by Davanum Srinivas <da...@gmail.com>.
here's a log snippet from my GBean's doStart:
14:31:15,843 INFO [AxisHTTPBean] TCCL :sun.misc.Launcher$AppClassLoader@53ba3d
14:31:15,843 INFO [AxisHTTPBean] GBean ClassLoader:
[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=org/apache/axis2]
Please note that i don't have the addAttribute with "classLoader" in
my GBEAN_INFO like all the other gbeans. (since i did not know how to
create the GBean programatically with a class loader and load it into
the kernel in my junit test case)
thanks,
dims
On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
> Now I'm confused. I thought these would be the exact same
> classloader. I thought there would only be one. Maybe David Jencks
> can help here.
>
> -dain
>
> On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
>
> > The class loader that loaded the GBean. Sorry, i forgot to mention
> > that.
> >
> > thanks,
> > dims
> >
> > On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
> >
> >> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
> >>
> >>
> >>> DJ mentioned that this is because the TCCL is set to the
> >>> configurations' classloader. So i had to forcibly set the context
> >>> class loader myself.
> >>>
> >>
> >> What did you forcibly set it to?
> >>
> >> -dain
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: TCCL in doStart
Posted by Dain Sundstrom <da...@iq80.com>.
Done.
Let me know if you have any problems.
-dain
On Oct 30, 2005, at 6:17 AM, Davanum Srinivas wrote:
> +1 from me to clean up the rest.
>
> thanks,
> dims
>
> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>
>> On Oct 29, 2005, at 11:57 AM, David Jencks wrote:
>>
>>
>>>
>>> On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote:
>>>
>>>
>>>
>>>> Setting the TCCL around lifecycle methods is one of the changes I
>>>> made in XBean. It turns out that there is a lot of code out there
>>>> that assumes the TCCL is properly set, so instead of requiring
>>>> everyone to write a wrapper class, I just set it. The reason we
>>>> removed most of the TCCL setting code from Geronimo was because it
>>>> was a major performance impact. I just think we went a little to
>>>> far :) The life cycle methods are rarely called and don't happen
>>>> in code paths where performance is critical. I think we should
>>>> change the GBeanInstance code to set the TCCL around doStart and
>>>> doStop.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>
>>> Fine with me. Do you agree that setting the TCCL while
>>> deserializing attribute values is unnecessary?
>>>
>>
>> I think the ObjectInputStreamEx handles all of our cases with an
>> explicit class loader, but we may want to leave the code there in
>> case a readObject or readReplace implementation tries to get the
>> TCCL. So I think it is unnecessary, but I see no harm is just
>> leaving that one there.
>>
>> -dain
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: TCCL in doStart
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me to clean up the rest.
thanks,
dims
On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
> On Oct 29, 2005, at 11:57 AM, David Jencks wrote:
>
> >
> > On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote:
> >
> >
> >> Setting the TCCL around lifecycle methods is one of the changes I
> >> made in XBean. It turns out that there is a lot of code out there
> >> that assumes the TCCL is properly set, so instead of requiring
> >> everyone to write a wrapper class, I just set it. The reason we
> >> removed most of the TCCL setting code from Geronimo was because it
> >> was a major performance impact. I just think we went a little to
> >> far :) The life cycle methods are rarely called and don't happen
> >> in code paths where performance is critical. I think we should
> >> change the GBeanInstance code to set the TCCL around doStart and
> >> doStop.
> >>
> >> What do you think?
> >>
> >
> > Fine with me. Do you agree that setting the TCCL while
> > deserializing attribute values is unnecessary?
>
> I think the ObjectInputStreamEx handles all of our cases with an
> explicit class loader, but we may want to leave the code there in
> case a readObject or readReplace implementation tries to get the
> TCCL. So I think it is unnecessary, but I see no harm is just
> leaving that one there.
>
> -dain
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: TCCL in doStart
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 29, 2005, at 11:57 AM, David Jencks wrote:
>
> On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote:
>
>
>> Setting the TCCL around lifecycle methods is one of the changes I
>> made in XBean. It turns out that there is a lot of code out there
>> that assumes the TCCL is properly set, so instead of requiring
>> everyone to write a wrapper class, I just set it. The reason we
>> removed most of the TCCL setting code from Geronimo was because it
>> was a major performance impact. I just think we went a little to
>> far :) The life cycle methods are rarely called and don't happen
>> in code paths where performance is critical. I think we should
>> change the GBeanInstance code to set the TCCL around doStart and
>> doStop.
>>
>> What do you think?
>>
>
> Fine with me. Do you agree that setting the TCCL while
> deserializing attribute values is unnecessary?
I think the ObjectInputStreamEx handles all of our cases with an
explicit class loader, but we may want to leave the code there in
case a readObject or readReplace implementation tries to get the
TCCL. So I think it is unnecessary, but I see no harm is just
leaving that one there.
-dain
Re: TCCL in doStart
Posted by David Jencks <da...@yahoo.com>.
On Oct 29, 2005, at 11:51 AM, Dain Sundstrom wrote:
> Setting the TCCL around lifecycle methods is one of the changes I made
> in XBean. It turns out that there is a lot of code out there that
> assumes the TCCL is properly set, so instead of requiring everyone to
> write a wrapper class, I just set it. The reason we removed most of
> the TCCL setting code from Geronimo was because it was a major
> performance impact. I just think we went a little to far :) The life
> cycle methods are rarely called and don't happen in code paths where
> performance is critical. I think we should change the GBeanInstance
> code to set the TCCL around doStart and doStop.
>
> What do you think?
Fine with me. Do you agree that setting the TCCL while deserializing
attribute values is unnecessary?
thanks
david jencks
>
> -dain
>
> On Oct 29, 2005, at 11:37 AM, David Jencks wrote:
>
>> I think my previous claims (possibly on IRC) are wrong.
>>
>> After looking at the code again, my understanding is that:
>>
>> when the gbean is loaded into the kernel, the TCCL is the
>> configuration classloader (see
>> Configuration.loadGBeans(ManageableAttributeStore attributeStore)
>> lines 296 ff.) Note the comment from Dain wondering why we are doing
>> this. I think this is a leftover attempt to solve the problem of
>> deserializing objects using the configuration classloader. We are
>> now solving this problem with the ObjectInputStreamExt class so I
>> think this TCCL setting is unnecessary.
>>
>> when the gbean implementation class constructor and doStart method is
>> called, the TCCL is indeterminate. I believe the idea is that if you
>> want to set the TCCL properly, you will include a classLoader
>> non-persistent "magic" attribute in the gbeanInfo and set the TCCL
>> yourself.
>>
>> Sorry for the confusion.
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>> On Oct 29, 2005, at 11:12 AM, Dain Sundstrom wrote:
>>
>>
>>> Now I'm confused. I thought these would be the exact same
>>> classloader. I thought there would only be one. Maybe David Jencks
>>> can help here.
>>>
>>> -dain
>>>
>>> On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
>>>
>>>
>>>> The class loader that loaded the GBean. Sorry, i forgot to mention
>>>> that.
>>>>
>>>> thanks,
>>>> dims
>>>>
>>>> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>>>>
>>>>
>>>>> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>>>>>
>>>>>
>>>>>
>>>>>> DJ mentioned that this is because the TCCL is set to the
>>>>>> configurations' classloader. So i had to forcibly set the context
>>>>>> class loader myself.
>>>>>>
>>>>>>
>>>>>
>>>>> What did you forcibly set it to?
>>>>>
>>>>> -dain
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Davanum Srinivas : http://wso2.com/blogs/
>>>>
>>>>
>>>
>>
>
Re: TCCL in doStart
Posted by Dain Sundstrom <da...@iq80.com>.
Setting the TCCL around lifecycle methods is one of the changes I
made in XBean. It turns out that there is a lot of code out there
that assumes the TCCL is properly set, so instead of requiring
everyone to write a wrapper class, I just set it. The reason we
removed most of the TCCL setting code from Geronimo was because it
was a major performance impact. I just think we went a little to
far :) The life cycle methods are rarely called and don't happen in
code paths where performance is critical. I think we should change
the GBeanInstance code to set the TCCL around doStart and doStop.
What do you think?
-dain
On Oct 29, 2005, at 11:37 AM, David Jencks wrote:
> I think my previous claims (possibly on IRC) are wrong.
>
> After looking at the code again, my understanding is that:
>
> when the gbean is loaded into the kernel, the TCCL is the
> configuration classloader (see Configuration.loadGBeans
> (ManageableAttributeStore attributeStore) lines 296 ff.) Note the
> comment from Dain wondering why we are doing this. I think this is
> a leftover attempt to solve the problem of deserializing objects
> using the configuration classloader. We are now solving this
> problem with the ObjectInputStreamExt class so I think this TCCL
> setting is unnecessary.
>
> when the gbean implementation class constructor and doStart method
> is called, the TCCL is indeterminate. I believe the idea is that
> if you want to set the TCCL properly, you will include a
> classLoader non-persistent "magic" attribute in the gbeanInfo and
> set the TCCL yourself.
>
> Sorry for the confusion.
>
> thanks
> david jencks
>
>
>
>
> On Oct 29, 2005, at 11:12 AM, Dain Sundstrom wrote:
>
>
>> Now I'm confused. I thought these would be the exact same
>> classloader. I thought there would only be one. Maybe David
>> Jencks can help here.
>>
>> -dain
>>
>> On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
>>
>>
>>> The class loader that loaded the GBean. Sorry, i forgot to
>>> mention that.
>>>
>>> thanks,
>>> dims
>>>
>>> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>>>
>>>
>>>> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>>>>
>>>>
>>>>
>>>>> DJ mentioned that this is because the TCCL is set to the
>>>>> configurations' classloader. So i had to forcibly set the context
>>>>> class loader myself.
>>>>>
>>>>>
>>>>
>>>> What did you forcibly set it to?
>>>>
>>>> -dain
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas : http://wso2.com/blogs/
>>>
>>>
>>
>
Re: TCCL in doStart
Posted by David Jencks <da...@yahoo.com>.
I think my previous claims (possibly on IRC) are wrong.
After looking at the code again, my understanding is that:
when the gbean is loaded into the kernel, the TCCL is the configuration
classloader (see Configuration.loadGBeans(ManageableAttributeStore
attributeStore) lines 296 ff.) Note the comment from Dain wondering
why we are doing this. I think this is a leftover attempt to solve the
problem of deserializing objects using the configuration classloader.
We are now solving this problem with the ObjectInputStreamExt class so
I think this TCCL setting is unnecessary.
when the gbean implementation class constructor and doStart method is
called, the TCCL is indeterminate. I believe the idea is that if you
want to set the TCCL properly, you will include a classLoader
non-persistent "magic" attribute in the gbeanInfo and set the TCCL
yourself.
Sorry for the confusion.
thanks
david jencks
On Oct 29, 2005, at 11:12 AM, Dain Sundstrom wrote:
> Now I'm confused. I thought these would be the exact same
> classloader. I thought there would only be one. Maybe David Jencks
> can help here.
>
> -dain
>
> On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
>
>> The class loader that loaded the GBean. Sorry, i forgot to mention
>> that.
>>
>> thanks,
>> dims
>>
>> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>>
>>> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>>>
>>>
>>>> DJ mentioned that this is because the TCCL is set to the
>>>> configurations' classloader. So i had to forcibly set the context
>>>> class loader myself.
>>>>
>>>
>>> What did you forcibly set it to?
>>>
>>> -dain
>>>
>>>
>>
>>
>> --
>> Davanum Srinivas : http://wso2.com/blogs/
>>
>
Re: TCCL in doStart
Posted by Dain Sundstrom <da...@iq80.com>.
Now I'm confused. I thought these would be the exact same
classloader. I thought there would only be one. Maybe David Jencks
can help here.
-dain
On Oct 29, 2005, at 10:58 AM, Davanum Srinivas wrote:
> The class loader that loaded the GBean. Sorry, i forgot to mention
> that.
>
> thanks,
> dims
>
> On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
>
>> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>>
>>
>>> DJ mentioned that this is because the TCCL is set to the
>>> configurations' classloader. So i had to forcibly set the context
>>> class loader myself.
>>>
>>
>> What did you forcibly set it to?
>>
>> -dain
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: TCCL in doStart
Posted by Davanum Srinivas <da...@gmail.com>.
The class loader that loaded the GBean. Sorry, i forgot to mention that.
thanks,
dims
On 10/29/05, Dain Sundstrom <da...@iq80.com> wrote:
> On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
>
> > DJ mentioned that this is because the TCCL is set to the
> > configurations' classloader. So i had to forcibly set the context
> > class loader myself.
>
> What did you forcibly set it to?
>
> -dain
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: TCCL in doStart
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 29, 2005, at 10:11 AM, Davanum Srinivas wrote:
> DJ mentioned that this is because the TCCL is set to the
> configurations' classloader. So i had to forcibly set the context
> class loader myself.
What did you forcibly set it to?
-dain