You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Paul Benedict <pb...@apache.org> on 2008/06/09 08:45:06 UTC
Needing an OSGi expert to help Struts
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
Re: Needing an OSGi expert to help Struts
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sahoo wrote:
> Stuart McCulloch wrote:
>> 2008/6/12 Toni Menzel <to...@gmx.de>:
>>
>>
>>> 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
>>
>>
> So what do Felix users do? Is there any plan to provide any such
> facilities?
In general, we'd recommend setting the context class loader yourself.
This is an area that might get addressed in the future by the spec, but
right now it is completely implementation dependent unless you do it
yourself.
-> richard
>
> Thanks,
> Sahoo
Re: Needing an OSGi expert to help Struts
Posted by Sahoo <Sa...@Sun.COM>.
Stuart McCulloch wrote:
> 2008/6/12 Toni Menzel <to...@gmx.de>:
>
>
>> 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
>
>
So what do Felix users do? Is there any plan to provide any such
facilities?
Thanks,
Sahoo
Re: Needing an OSGi expert to help Struts
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Since threads inherit their CCL, you can easily create your own TCCL by
creating your own Felix launcher thats sets the TCCL of the main thread
to be whatever you want, Felix will end up using that since we don't
change it...at least that is my understanding.
If someone creates this, please post it to a JIRA issue so we can all
debate whether it would be worthwhile to include it or not.
I am not personally against it, but I would have to see the proposed
solution.
-> richard
Saminda Abeyruwan 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
>>
>>
>>
>>
>
>
>
Re: Needing an OSGi expert to help Struts
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Jun 14, 2008 at 1:23 AM, Paul Benedict <pb...@apache.org> wrote:
> We just have to figure out how to do that in Struts. What would it mean to
> configure Struts in an OSGi container?
Well, it seems that you guys have not defined what you mean by "OSGify
Struts". There are several levels possible.
As you have probably noted, the main issue is regarding the "loading
of a class from a string" and related issues.
One possible way to become OSGi-friendly is to locate all places where
you do some form of ClassLoader.loadClass() or Class.forName() and
delegate that to an implementation of a ClassFactory (or whatever you
want to call it) and that ClassFactory implementations can register
themselves into Struts. Your own default implementation use the
ThreadContextClassLoader, whereas in the OSGi case, I would suggest an
implementation that looks for ClassFactory services to delegate to.
Whether or not you provide this final bit is less important...
Also note that if you do any kind of deserialization, you have
additional class loading concerns in there...
Cheers
Niclas
Re: Needing an OSGi expert to help Struts
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <pb...@apache.org> 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 <sa...@gmail.com>
> 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
Re: Needing an OSGi expert to help Struts
Posted by Paul Benedict <pb...@apache.org>.
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 <sa...@gmail.com>
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
>
Re: Needing an OSGi expert to help Struts
Posted by Saminda Abeyruwan <sa...@gmail.com>.
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
Re: Needing an OSGi expert to help Struts
Posted by Stuart McCulloch <st...@jayway.net>.
2008/6/12 Toni Menzel <to...@gmx.de>:
> 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" <sa...@gmail.com>
> > An: dev@felix.apache.org
> > Betreff: Re: Needing an OSGi expert to help Struts
>
> > On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <he...@ungoverned.org>
> > 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@gmail.com>
> > >> wrote:
> > >>
> > >>
> > >>
> > >>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
Re: Needing an OSGi expert to help Struts
Posted by Toni Menzel <to...@gmx.de>.
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" <sa...@gmail.com>
> An: dev@felix.apache.org
> Betreff: Re: Needing an OSGi expert to help Struts
> On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <he...@ungoverned.org>
> 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@gmail.com>
> >> wrote:
> >>
> >>
> >>
> >>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
Re: Needing an OSGi expert to help Struts
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On Thu, Jun 12, 2008 at 2:48 PM, Richard S. Hall <he...@ungoverned.org>
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@gmail.com>
>> wrote:
>>
>>
>>
>>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
Re: Needing an OSGi expert to help Struts
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <ni...@gmail.com>
> wrote:
>
>
>> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
>>>>
>>>>
>>>>
>
>
>
>
Re: Needing an OSGi expert to help Struts
Posted by Saminda Abeyruwan <sa...@gmail.com>.
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
Re: Needing an OSGi expert to help Struts
Posted by Paul Benedict <pb...@apache.org>.
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 <sa...@gmail.com>
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
>
Re: Needing an OSGi expert to help Struts
Posted by Saminda Abeyruwan <sa...@gmail.com>.
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 <ni...@gmail.com>
wrote:
> On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
Re: Needing an OSGi expert to help Struts
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Jun 10, 2008 at 3:42 AM, Sahoo <Sa...@sun.com> 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
>>
>>
>
Re: Needing an OSGi expert to help Struts
Posted by Paul Benedict <pb...@apache.org>.
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 <ki...@interfree.it> 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
Re: Needing an OSGi expert to help Struts
Posted by Stefano Lenzi <ki...@interfree.it>.
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
>>
>>
>
>
Re: Needing an OSGi expert to help Struts
Posted by Sahoo <Sa...@Sun.COM>.
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
>
>