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" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: Needing an OSGi expert to help Struts > 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
