[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] ContextFinder stops at first bundle class loader

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



Inactive hide details for Gunnar Wagenknecht ---11/25/2007 11:04:23 AM---Hi,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

GIF image

GIF image