[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] ContextFinder stops at first bundle class loader
|
How do buddy classloading and DynamicImport-Package compare with
regards to performance ?
I've had very bad experiences performance-wise with buddy classloading
and a global policy...
Tom
On Nov 26, 2007 1:10 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
>
>
> The ContextFinder is designed to simply convert context classloader
> delegations into simple Class.forName calls. Then we can use standard OSGi
> delegation to find the classes which are trying to be loaded (i.e through
> Import-Package, Require-Bundle, etc). Unfortunately standard OSGi delegation
> does not really help for 3rd party libraries which are accustomed to using
> the context classloader to load things which are not known at development
> time (which means you cannot use any standard OSGi constraints like
> Import-Package). You have a couple of options. 1) use DynamicImport-Package:
> * 2) use Equinox buddy classloading.
>
> I try to avoid DynamicImport-Package as much as possible because it has
> several drawbacks (like risk of replacing any of your private classes
> including your bundle activator from other exporters!!). Instead you should
> try using the buddy classloading mechanism. Adding the following header
> should give you the behavior you are looking for:
>
> Eclipse-BuddyPolicy: dependent
>
> HTH.
>
> Tom
>
>
>
> Gunnar Wagenknecht ---11/25/2007 11:04:23 AM---Hi,
>
>
>
> From:
>
> Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
>
> To:
> equinox-dev@xxxxxxxxxxx
>
> Date:
> 11/25/2007 11:04 AM
>
> Subject:
> [equinox-dev] ContextFinder stops at first bundle class loader
> ________________________________
>
>
>
>
>
> Hi,
>
> Is there a specific reason why the ContextFinder stops at the first
> bundle class loader?
>
> I'm trying to integrate an existing framework into the SSE world. During
> de-serialization it wants to load classes and the ContextFinder would be
> really helpful here but it stops at the first bundle class loader which
> prevents a good bundle architecture.
>
> Example:
> * ConcreteServlet definied in mybundle
> * ConcreteServlet extends BaseServlet
> * BaseServlet defined in frameworkbundle
> * mybundle imports package for BaseServlet from frameworkbundle
> * BaseServlet#decode(Request) calls code in frameworkbundle which uses
> context class loader which triggers ContextFinder to load classes
> (defined in mybundle)
> * ContextFinder stops at frameworkbundle's class loader but
> frameworkbundle does not see classes in mybundle.
>
> If ContextFinder would simply look further and try additional bundle
> class loaders up in the stack it would eventually get to mybundle's
> class loader and everything would work.
>
> Is there a specific reason for this design? I could imagine that there
> could by some circularity or other problems. But if there was no
> specific reason I wonder if I should open an enhancement request for
> ContextFinder?
>
> -Gunnar
>
>
> --
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx
> http://wagenknecht.org/
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>