Needing an OSGi expert to help Struts

[pbenedict]

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

[Sahoo]

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?

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
>
>  

[Stefano Lenzi]

Sahoo 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?

Also, where can we find the sources of the project that you are trying
to "OSGize"?
Are you using maven along with the maven-bundle-plugin for the "OSGize"
process?

Ciao,
Stefano Lenzi

>
> 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
>>
>>  
>
>

[pbenedict]

Shaoo, Stefano,

Thanks for responding. I created a miniature Maven 2 repository holding the
snapshots of the libraries. Being a repo, it contains the POM for you to
inspect as well:

http://people.apache.org/~pbenedict/struts-osgi/

Sources from SVN:
http://svn.apache.org/viewvc/struts/struts1/trunk/

We are using the maven-bundle-plugin. I have to research the classloading
question, because I don't remember that off-hand. Niall, would you happen to
know?

Paul

On Tue, Jun 10, 2008 at 2:59 AM, Stefano Lenzi <kismet@...> wrote:

> Sahoo 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?
>>
>
> Also, where can we find the sources of the project that you are trying to
> "OSGize"?
> Are you using maven along with the maven-bundle-plugin for the "OSGize"
> process?
>
> Ciao,
> Stefano Lenzi

[Niall Pemberton-2]

On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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-3]

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 <niall.pemberton@...>
wrote:

> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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

[pbenedict]

Saminda,

Here's the code pointed out by Niall:

>    ClassLoader loader = Thread.currentThread().getContextClassLoader();
>    if (loader == null) {
>        loader = this.getClass().getClassLoader();
>    }

I wouldn't imagine it would be difficult to refactor such logic into a
replaceable method. What I'd like to know is, if you think it contradicts
OSGi behavior, what should it be to be OSGi compliant?

Paul

On Wed, Jun 11, 2008 at 6:08 AM, Saminda Abeyruwan <samindaa@...>
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
>

[Saminda Abeyruwan-3]

Saminda,

>
> Here's the code pointed out by Niall:
>
> >    ClassLoader loader = Thread.currentThread().getContextClassLoader();
> >    if (loader == null) {
> >        loader = this.getClass().getClassLoader();
> >    }
>
>
>
> My concern is "ClassLoader loader =

Thread.currentThread().getContextClassLoader()" reference is not null, the
"loader" will be referenced the TCCL, which is not backed up by the module
layer.  In Felix,"Thread.currentThread().getContextClassLoader()" points to
the application classloader. In this case, If the later logic would try to
load resources/classes from "loader" it could only see resources/classes
from app classloader.

Thank you!

Saminda

--
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

[Richard S. Hall]

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.

-> 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 <niall.pemberton@...>
> wrote:
>
>  
>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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-3]

On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <heavy@...>
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 <
>> niall.pemberton@...>
>> wrote:
>>
>>
>>
>>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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

[Toni Menzel-2]

Just a shot in: speaking of legacy code (non osgi) using TCCL:
The makewave guys explain bytecode weaving to fix those "broken" code: google for "makewave  everything can be a bundle" to get some slides about that.
Sure, this just shifts the problem arround but could help anyway.

Toni



-------- Original-Nachricht --------
> Datum: Thu, 12 Jun 2008 16:15:57 +0530
> Von: "Saminda Abeyruwan" <samindaa@...>
> An: dev@...
> Betreff: Re: Needing an OSGi expert to help Struts

> On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <heavy@...>
> 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 <
> >> niall.pemberton@...>
> >> wrote:
> >>
> >>
> >>
> >>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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

[Stuart McCulloch-3]

2008/6/12 Toni Menzel <tonimenzel@...>:

> Just a shot in: speaking of legacy code (non osgi) using TCCL:
> The makewave guys explain bytecode weaving to fix those "broken" code:
> google for "makewave  everything can be a bundle" to get some slides about
> that.
> Sure, this just shifts the problem arround but could help anyway.
>

there's also the "ContextFinder" classloader implementation from the
Equinox project, which you can set as your TCCL and it will try to find
the right classloader based on the current call stack - although like the
bytecode weaving solution, it's not 100% foolproof...

note the OSGi specification does not mandate a specific TCCL setting

Toni

>
> -------- Original-Nachricht --------
> > Datum: Thu, 12 Jun 2008 16:15:57 +0530
> > Von: "Saminda Abeyruwan" <samindaa@...>
> > An: dev@...
> > Betreff: Re: Needing an OSGi expert to help Struts
>
> > On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <heavy@...>
> > 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 <
> > >> niall.pemberton@...>
> > >> wrote:
> > >>
> > >>
> > >>
> > >>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sahoo@...> 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
>

--
Cheers, Stuart

[Saminda Abeyruwan-3]

Hi All,

Thank you for your help to clarify the TCCL issue. I really appreciate this.

Would Felix  provide an extension point to set the TCCL we wanted to use.
(ex: instance of ContextFinder). Since the  classloader delegation is handle
within the framework, I am wondering is it possible to change the default
behaviour as wanted.

Thank you!

Saminda

>
> there's also the "ContextFinder" classloader implementation from the
> Equinox project, which you can set as your TCCL and it will try to find
> the right classloader based on the current call stack - although like the
> bytecode weaving solution, it's not 100% foolproof...
>
> note the OSGi specification does not mandate a specific TCCL setting
>
>
>

--
Saminda Abeyruwan

Senior Software Engineer
WSO2 Inc. - www.wso2.org

[pbenedict]

In a discussions about this, we were looking at what Commons Digester does:
http://commons.apache.org/digester/commons-digester-1.8/docs/api/org/apache/commons/digester/Digester.html#getUseContextClassLoader()

It appears you can direct Digester to what ClassLoader should be used.

We just have to figure out how to do that in Struts. What would it mean to
configure Struts in an OSGi container? It's typically configured in web.xml
-- does that have any bearing? Spring Framework supplies a bunch of OSGified
JEE libraries. So I hope to learn from them some tips. If anyone else has an
idea, I'd like to hear.

Paul

On Fri, Jun 13, 2008 at 12:01 PM, Saminda Abeyruwan <samindaa@...>
wrote:

> Hi All,
>
> Thank you for your help to clarify the TCCL issue. I really appreciate
> this.
>
> Would Felix  provide an extension point to set the TCCL we wanted to use.
> (ex: instance of ContextFinder). Since the  classloader delegation is
> handle
> within the framework, I am wondering is it possible to change the default
> behaviour as wanted.
>
> Thank you!
>
> Saminda
>
>
>
> >
> > there's also the "ContextFinder" classloader implementation from the
> > Equinox project, which you can set as your TCCL and it will try to find
> > the right classloader based on the current call stack - although like the
> > bytecode weaving solution, it's not 100% foolproof...
> >
> > note the OSGi specification does not mandate a specific TCCL setting
> >
> >
> >
>
>
> --
> Saminda Abeyruwan
>
> Senior Software Engineer
> WSO2 Inc. - www.wso2.org
>

[Alin Dreghiciu]

I do not know about other HttpService implementations but Pax Web sets
the TCCL prior invoking the servlet/filter/listeners/jsps to the class
loader that registered them and resets the TCCL back to the value it
was before invocation.

If you have a struts app you can give it a try very easily following
the sample I made for Wicket Example or Spring Petclinic:
http://wiki.ops4j.org/confluence/x/oANN

The examples takes Wicket war without any change (without adding osgi
metatdata) and it works out of the box using Pax Web Extender and Pax
WAR url handler to add the osgi headers on the fly. You do not have to
use the war url handler if your artifacts are already osgi-fied.
For Spring Petclinic some modifications are required but is due to
some limitations that Spring has while discovering Controllers
automatically.

HTH,
Alin

On Fri, Jun 13, 2008 at 8:23 PM, Paul Benedict <pbenedict@...> wrote:

> In a discussions about this, we were looking at what Commons Digester does:
> http://commons.apache.org/digester/commons-digester-1.8/docs/api/org/apache/commons/digester/Digester.html#getUseContextClassLoader()
>
> It appears you can direct Digester to what ClassLoader should be used.
>
> We just have to figure out how to do that in Struts. What would it mean to
> configure Struts in an OSGi container? It's typically configured in web.xml
> -- does that have any bearing? Spring Framework supplies a bunch of OSGified
> JEE libraries. So I hope to learn from them some tips. If anyone else has an
> idea, I'd like to hear.
>
> Paul
>
> On Fri, Jun 13, 2008 at 12:01 PM, Saminda Abeyruwan <samindaa@...>
> wrote:
>
>> Hi All,
>>
>> Thank you for your help to clarify the TCCL issue. I really appreciate
>> this.
>>
>> Would Felix  provide an extension point to set the TCCL we wanted to use.
>> (ex: instance of ContextFinder). Since the  classloader delegation is
>> handle
>> within the framework, I am wondering is it possible to change the default
>> behaviour as wanted.
>>
>> Thank you!
>>
>> Saminda
>>
>>
>>
>> >
>> > there's also the "ContextFinder" classloader implementation from the
>> > Equinox project, which you can set as your TCCL and it will try to find
>> > the right classloader based on the current call stack - although like the
>> > bytecode weaving solution, it's not 100% foolproof...
>> >
>> > note the OSGi specification does not mandate a specific TCCL setting
>> >
>> >
>> >
>>
>>
>> --
>> Saminda Abeyruwan
>>
>> Senior Software Engineer
>> WSO2 Inc. - www.wso2.org
>>
>

--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places