[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] help understanding osgi.parentClassLoader
- From: nebulae <shravan.mishra@xxxxxxxxx>
- Date: Mon, 2 Jun 2008 14:38:28 -0400
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pqP+faIunH2WjTXHEnTdJXaUUyKfWiHySNX4o2p3mIRZR0xtxtSa5fxJUqg0QNvuWnvgQNLcL+b/rFSsoQJfSQkk0NFvCIDoqViZbihr90ScqpszT+cQUb5FYa4UcGF996ltm+Cx2YPg72s9MVcn4l4ejMH9Tdz3HSi5eAnjmDg=
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
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.
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:
>> I'm new to OSGI so please bear with me if they are basically naive
>> 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
>> 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
> 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
> 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.
> equinox-dev mailing list