felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toni Menzel" <tonimen...@gmx.de>
Subject Re: Needing an OSGi expert to help Struts
Date Thu, 12 Jun 2008 11:05:24 GMT
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@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

Mime
View raw message