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 <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
