felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: Needing an OSGi expert to help Struts
Date Thu, 12 Jun 2008 14:43:38 GMT
2008/6/12 Toni Menzel <tonimenzel@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" <samindaa@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 <heavy@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 <Sahoo@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message