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

[nebulae <shravan.mishra@xxxxxxxxx>]

I'm sorry I sent my email a little too fast, I still had the
parentclassloader set as app.

So now my question is how else can it work if I don't supply app has
the loader given the scenario I described in my previous email.

Thanks
Shravan



On Mon, Jun 2, 2008 at 2:38 PM, nebulae <shravan.mishra@xxxxxxxxx> wrote:
> 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
>>
>>
>