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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > To: > equinox-dev@eclipse.org > > 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 > [EMAIL PROTECTED] > http://wagenknecht.org/ > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev