parentClassloader parameter

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

parentClassloader parameter

Ugo Taddei
Hi,

first things first, the
http://udig.refractions.net/tutorials/SDKQuickstart.pdf has a typo on
page 15. It says:

-Dosgi.parentClassload=ext

but it should read

-Dosgi.parentClassloader=ext

As shown on the screenshot.

now to the question :-)

Why do I need this? I suspect it's to do with the way geotools loads JAI
(or at least I vaguely remember something like that). Is there a way to
avoid this? For example, if I define my own plugin and include the jai jars?

Otherwise one is forced to release a complete JRE along with the
product, which may be an advantage on some occasions, but not always.

Thoughts? Hints? Tips?

Thanks in advance,

Ugo
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: parentClassloader parameter

Andrea Antonello
Hi Ugo,
I am gonna add some untested thoughts.

> first things first, the
> http://udig.refractions.net/tutorials/SDKQuickstart.pdf has a typo on page
> 15. It says:
>
> -Dosgi.parentClassload=ext
>
> but it should read
>
> -Dosgi.parentClassloader=ext
>
> As shown on the screenshot.
>
> now to the question :-)
>
> Why do I need this? I suspect it's to do with the way geotools loads JAI (or
> at least I vaguely remember something like that). Is there a way to avoid
> this? For example, if I define my own plugin and include the jai jars?

That should do it. Btw, if you put the native jai libs in the root of
the plugin they will also be picked.

Hmmm, but then if it was so easy, why would we deliver the jai
addicted jre with udig? :)

Good question,
Andrea


> Otherwise one is forced to release a complete JRE along with the product,
> which may be an advantage on some occasions, but not always.
>
> Thoughts? Hints? Tips?
>
> Thanks in advance,
>
> Ugo
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: parentClassloader parameter

Ugo Taddei
Hi Andrea,

thanks for the quick answer!

andrea antonello wrote:

> Hi Ugo,
> I am gonna add some untested thoughts.
>
>> first things first, the
>> http://udig.refractions.net/tutorials/SDKQuickstart.pdf has a typo on page
>> 15. It says:
>>
>> -Dosgi.parentClassload=ext
>>
>> but it should read
>>
>> -Dosgi.parentClassloader=ext
>>
>> As shown on the screenshot.
>>
>> now to the question :-)
>>
>> Why do I need this? I suspect it's to do with the way geotools loads JAI (or
>> at least I vaguely remember something like that). Is there a way to avoid
>> this? For example, if I define my own plugin and include the jai jars?
>
> That should do it. Btw, if you put the native jai libs in the root of
> the plugin they will also be picked.

I'll try this out.

>
> Hmmm, but then if it was so easy, why would we deliver the jai
> addicted jre with udig? :)

Because
1) to deliver a JRE prevents the user from having to load her own

2) so we ensure uDig runs with the JRE we want

3) we don't/didn't realise there's a way to avoid this?

4) we love doing easy things the hard way ;-)

>
> Good question,
> Andrea

When I find some time, I'll try to read about the subject and try your
suggestion.

Cheers,

Ugo

>
>
>> Otherwise one is forced to release a complete JRE along with the product,
>> which may be an advantage on some occasions, but not always.
>>
>> Thoughts? Hints? Tips?
>>
>> Thanks in advance,
>>
>> Ugo
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: parentClassloader parameter

Jody Garnett-2
In reply to this post by Ugo Taddei
On 29/04/2010, at 6:43 PM, Ugo Taddei wrote:

Hi,

first things first, the http://udig.refractions.net/tutorials/SDKQuickstart.pdf has a typo on page 15. It says:

-Dosgi.parentClassload=ext

but it should read

-Dosgi.parentClassloader=ext

As shown on the screenshot.

Eeek! 

now to the question :-)

Why do I need this? I suspect it's to do with the way geotools loads JAI (or at least I vaguely remember something like that).

Sort of; the actual setting asks Eclipse to include the "boot classpath" in its parent classloader. So for each classloader it creates; the classloader includes JRE classes; and JRE extensions.  There are some more options described here:

osgi.frameworkParentClassloader
the classloader type to use as the parent classloader for the the Framework. The valid types are the following:
  • app - the application classloader.
  • boot - the boot classloader.
  • ext - the extension classloader.
  • current - the classloader used to load the equinox launcher.

Is there a way to avoid this? For example, if I define my own plugin and include the jai jars?

An excellent question (sigh!). We need this to use the JAI - as baked into the JRE.
This is require to get hardware acceleration as I understand it. If using the pure java JAI jars from your own plugin are not going to be able to reach out and use the DLLs or SO files.
- We tried including the files in a platform specific plugin (similar to how SWT is shipped) but you will need to search the archive or ask Jesse to find how that worked out.
- to try in pure java mode
-- you could remove the "excludes" in the refresh.xml script and add them to net.refractions.udig.libs - just to see if it works
-- you can try bundling them up in your own plugin; and asking net.refractions.udig.libs to depend on that plugin and see if it will run in pure java mode

But I would not expect native implementation to work with out more effort.

Ideas: One thing to do is to check how the Eclipse JOGL or Eclipse Java3D integration is done by other projects and see if we can learn from there experience.



Otherwise one is forced to release a complete JRE along with the product, which may be an advantage on some occasions, but not always.

Agreed. One alternative is to ask users to install JAI / ImageIO (and ImageIO-ext) into their system Java; or indeed have your installer download + install for them only if neeeded

Thoughts? Hints? Tips?

Thanks in advance,

Please report back; I would love to here your experience.

There is one added complication (or tip?). I see a number of JAI plugins already included in uDig; and it looks like it is willing to install a pure Java form of JAI into the JRE itself? We would need to talk to Jesse for details.

Jody


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: parentClassloader parameter

Jody Garnett-2
In reply to this post by Ugo Taddei

On 29/04/2010, at 7:01 PM, Ugo Taddei wrote:

> Because
> 1) to deliver a JRE prevents the user from having to load her own
- check; although we could also have an installer option now that we have an installer

> 2) so we ensure uDig runs with the JRE we want
- mostly useful when working in constrained government environments that have standardised on Java 5 (not kidding!)

> 3) we don't/didn't realise there's a way to avoid this?
- we think there is a way to avoid it - since SWT can do something; but we are not sure exactly how. Developers have wasted weeks previously - perhaps the documentation story has improved since last time? Check archives to see where they got stuck.

> 4) we love doing easy things the hard way ;-)

Actually parentClassloader was much easier then our earlier attempts

> When I find some time, I'll try to read about the subject and try your suggestion.

Yeah!

Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel