On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <[EMAIL PROTECTED]>
wrote:
> Felix does not set the TCCL. The TCCL is inherited from the thread that
> starts a thread, but Felix itself doesn't set it. From the JavaDoc for
> getContextClassLoader():
>
> "Returns the context ClassLoader for this Thread. The context ClassLoader
> is provided by the creator of the thread for use by code running in this
> thread when loading classes and resources. If not set, the default is the
> ClassLoader context of the parent Thread. The context ClassLoader of the
> primordial thread is typically set to the class loader used to load the
> application."
>
> In short, though, it doesn't sound like you would want to check this class
> loader first, because OSGi specifically blocks access to the class path.
Since TCCL is the Classloader of the primordial thread, if someone tries to
load resources/classes from TCCL inside a bundle rather than using bundle
API or bundle classloader, which will result in resources/classes not
found.
Most of the legacy code uses TCCL to load resources/classes assuming
application classloader has the relevant resources/classes. Thus, if this
code (jar) has re-package as a bundle to be used in an OSGi environment,
allowing TCCL to load resources/classes wouldn't find those
resources/classes. Even Fragment-Host has been used with this bundle to
extend the classpath, TCCL wouldn't see them, as Fragment-Host is not a part
of primordial thread.
Inside a bundle, wouldn't TCCL to be able to access bundle resources/classes
as from bundle API or bundle classloader. Otherwise converting legacy code
to OSGi bundle would require code level changes, which is IMHO would be very
risky.
Thank you!
Saminda
>
> -> richard
>
>
> Saminda Abeyruwan wrote:
>
>> Hi All,
>>
>> Regarding the TCCL, wonder checking null for TCCL and fallback to Class
>> classloader would solve the whole problem. Even in embedded case, when
>> check
>> for TCCL it will give you the application classpath. i.e, Felix set
>> application classpath to TCCL and it is not OSGi based. OSGi sepc doesn't
>> cover this phenomenon properly and different OSGi implementation treats
>> this
>> differently. In Felix, TCCL wouldn't be null. Thus, if I assume correct,
>> in
>> order to get Struts bundle working struts beans have to be in application
>> classpath. If that the case, it would contradict with OSGi modularity
>> concept.
>>
>> Thank you!
>>
>> Saminda
>>
>> On Tue, Jun 10, 2008 at 7:15 PM, Niall Pemberton <
>> [EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Paul,
>>>>
>>>> Would you mindly briefly telling us what changes you had to do. What
>>>>
>>>>
>>> class
>>>
>>>
>>>> loader does the OSGi-ed Struts use to load application specific classes
>>>>
>>>>
>>> and
>>>
>>>
>>>> resources?
>>>>
>>>>
>>> So far all thats been done has been to use the maven plugin to add the
>>> OSGi manifest entries - so the class loader used is currently
>>> unchanged. From a quick scan of the code the core parts of Struts try
>>> to get the context class loader, but fall back to the current class's
>>> ClassLoader if that is null - something like:
>>>
>>> ClassLoader loader = Thread.currentThread().getContextClassLoader();
>>> if (loader == null) {
>>> loader = this.getClass().getClassLoader();
>>> }
>>>
>>> There are a few instances of it just using the current class's class
>>> loader in more peripheral functionality
>>>
>>> Niall
>>>
>>>
>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Paul Benedict wrote:
>>>>
>>>>
>>>>> At the Struts project, we just OSGified our libraries with the
>>>>> maven-bundle-plugin. We need some verification help though. Is anyone
>>>>> on
>>>>> the
>>>>> Felix team familiar enough with Struts to also look at the SNAPSHOT
>>>>>
>>>>>
>>>> Struts
>>>
>>>
>>>> libraries, maybe load them, and check out their MANIFEST? Since these
>>>>> libraries will be primarily used in a web container, I don't know how
>>>>>
>>>>>
>>>> that
>>>
>>>
>>>> is different than a "regular" library.
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>>
>
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
