help understanding osgi.parentClassLoader

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.

System.bundle is the framework bundle which exports packages through

Question regarding class loader and getPackages()

Re: help understanding osgi.parentClassLoader

Re: Question regarding class loader and getPackages()

Re: Question regarding class loader and getPackages()

Re: Question regarding class loader and getPackages()

Re: help understanding osgi.parentClassLoader

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@...> wrote:
> equinox-dev-bounces@... 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@...
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>

Re: help understanding osgi.parentClassLoader

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@...> 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@...> wrote:
>> equinox-dev-bounces@... 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@...
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>

copyrights only contributions

jBPM or other workflow engine

Hi,
jBPM and other BPMs use POJOs to 'back' the workflow -> for decisions  
and actions in the workflow Classes are 'called'

Now, I specify only to call e.g. de.pich.domi.MyClass. A POJO which  
only must be on the class path... this doesn't  work with Classes in a  
OSGI Bundle, does it?

I guess i'd need 'proxy classes' outside the framework which in turn  
call into the service?

Regards,
Dominik