Re: [equinox-dev] help understanding osgi.parentClassLoader

[nebulae <shravan.mishra@xxxxxxxxx>]

Thanks a lot Tom, you're right xerces.jar was indeed in the ext dir
and that's why osgi.parentClassloader=app worked and so would ext.

I was able to fix this problem by supplying DynamicImport-Package: *
in one of my bundles. Here are the details:


I have a declarative service let's say in a bundle - Ads.
Now Ads calls a leagcy code which has been wrapped as a bundle and
loaded in the OSGI environ - Lega

Ads is calling Lega's APIs.

Now Lega is calling Jdom which  in turn calls
org.sax.helpers.XMLReaderFactory.loadClass which is in rt.jar.

Now I'm assuming rt.jar is using class.forName() to load a Sax driver
from xerces.jar.

What I did was put DynamicImport-Package in Ads's manifest and it
appears to work fine.


Can you please explain the flow here in your view that made it work.

Thanks a lot.

Shravan





On Mon, Jun 2, 2008 at 10:12 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/01/2008 10:36:04 PM:
>>
>> Hi,
>>
>> I'm new to OSGI so please bear with me if they are basically naive
>> questions.
>> I'm using Equinox's latest version, I've gone through the mailing
>> lists and OSGI's core manual especailly the Module layer section and
>> found lots of very important information.
>>
>> Under Eclipse's runtime options there is
>>
>> osgi.parentClassLoader
>>     the classloader type to use as the parent classloader for all
>> bundles installed in the Framework. The valid types are the following:
>>
>>         * app - the application classloader.
>>         * boot - the boot classloader.
>>         * ext - the extension classloader.
>>         * fwk - the framework classloader.
>>
>>
>> So my questions are -
>>
>> How do you decide which type to use as your parent class loader (pcl) ?
>>
>> Basically these 4 types of classloaders load classes from different
>> classpaths (boot and system), right?
>>
>> What does it mean to be an extension classloader? In the spec it says
>> the extension bundles are fragments (framework or bootclasspath) but
>> fragments don't have their classloaders.
>
> Here extension class loader refers to the VM's extension class loader
> which loads classes from the ext/ directory of the VM.
>
>>
>> System.bundle is the framework bundle which exports packages through
>> pcl  using org.osgi.framework.system.packages then why there is
>> specific fwk type?
>
> The fwk type specifies the actual class loader which loads the
> Equinox framework.  I would avoid this setting if possible, it only
> kind of makes sense when embedding the Framework in your own
> Java application and you need to expose the class loader used to
> load the framework.
>
>>
>> If all the classes starting with java and the one's specified by
>> org.osgi.framework.bootdelegation are to be loaded by pcl then what is
>> boot type?
>
> The boot type specifies the "boot" classloader of the VM.  This is
> the default used by Eclipse.  This class loader is used to load the
> class built into the VM (java.* and others packages, javax.xml etc.).
>
>>
>> what does app mean, which classloader is this referring to?
>
> This is the application class loader setup by the VM to launch an
> application.  The VM sets up the classloaders with the following
> hierarchy
>
> app->ext->boot
>
> In eclipse the app class loader is used to load the boot strap
> launcher (org.eclipse.equinox.launder jar).  This code creates
> another classloader for the framework to launch (fwk)
>
>>
>> I was having some classloading issues with xerces parser and when I
>> switched to app it suddenly worked, I really want to understand what
>> happened.
>>
>
> More than likely the xerces stuff you were trying to load came from
> the VM's extension classloader then.  With that said, all of this is
> not really recommended in OSGi.  The parent class loader should
> really only be used for java.* packages.  This allows for much more
> control over what packages you get and what versions.  Depending on
> the packages from the app, ext or boot class loader in the VM without
> specifying constraints (Import-Package/Require-Bundle) is not a good
> practice because your bundle may resolve in an environment where the
> package is not available from the VM.
>
>> Clarifications of the above questions will be very much appreciated.
>>
>> Thanks much.
>>
>> Shravan
>>
>
> Tom.
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>