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 <[EMAIL PROTECTED]> 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/
