[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
>
>