[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Equinox Declarative Services : Context Class Loader
- From: Sameera Jayasoma <sameera.madushan@xxxxxxxxx>
- Date: Tue, 31 Mar 2009 17:10:12 +0530
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Jc1YReILGWyWowNdObwybur4K9g++kncUSepSqYDVyLne03dCh8+fYf7r0UHEQULbv a6G222gBpDc2puARKDSH8GlY9Izp5NcOnUyvKIK+sdP+ZgUfF6AcOVx0vk4KcwhIRWBa VLeJeWm/kfYtJrfOK8IsTXN67h/lxQF3uzzQo=
Thanks for the quick reply. See my comments below.
On Tue, Mar 31, 2009 at 4:49 PM, Neil Bartlett <njbartlett@xxxxxxxxx>
The question is, what did you expect instead of null?
When services or callbacks are invoked this context class loader is not null. It is the same in all the threads before using Declarative Services. So I expected the same.
The OSGi spec does not specify what the thread context classloader
(TCCL) should be when services or callbacks are invoked, therefore
components should not rely on it being set to anything in particular.
You can of course set the TCCL explicitly at the start of your
The reason for this, incidentally, is that TCCLs are intended to
support the concept of a global "application", and they are not really
a good fit with the classloading model in OSGi.
I also agree with this point. As you have mentioned the problem is with the legacy libraries. They heavily depend on TCCL.