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 <[EMAIL PROTECTED]> 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 <[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
