[RFC] Netx: some native libraries are not found

[Omair Majid]

On 06/30/2010 05:01 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com>  [2010-06-29 16:35]:
>> On 06/29/2010 02:06 PM, Deepak Bhole wrote:
>>> * Omair Majid<omajid at redhat.com>   [2010-06-21 10:33]:
>>>> Hi,
>>>>
>>>> There is a bug in the current version of Netx that fails to find
>>>> some native libraries [1][2].
>>>>
>>>> In the current implementation of Netx, one classloader is created
>>>> per JNLP file; for JNLP files loaded as extensions, the classloaders
>>>> share information about where to find resources. Unfortunately, they
>>>> do not share any information about where to find native libraries.
>>>> This makes Web Start applications with extensions that use native
>>>> libraries fail. The proposed patch [3] fixes this.
>>>>
>>>> Any comments concerns? Should I go ahead and commit this fix?
>>>>
>>>
>>> Patch looks good to me. Assuming you have tested it, please go ahead and
>>> commit.
>>>
>>
>> On furthur testing, I found an issue with the patch I had posted. I
>> had to change the check for extLoader and baseLoader from
>>   if (baseLoader != null)
>> to
>>   if (baseLoader != null&&  baseLoader != loader)
>> which makes sense to me: adding urls and native directories
>> repeatedly to the same loader has no point.
>>
>
> Why would the directories and urls get added again? That would only
> happen if the extension loaders had duplicate paths, which is really a
> bug in the jnlp...
>
> Or do you know of cases where it does it multiple times even if the jnlp
> specifies it only once?
>

An example of an application that demonstrates the behaviour is Jake 
[1]. Without that check we get a ConcurrentModificationException:

java.util.ConcurrentModificationException
	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
	at java.util.LinkedList$ListItr.next(LinkedList.java:713)
	at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:258)
	at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:293)
	at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeExtensions(JNLPClassLoader.java:312)
	at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:159)
	at 
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:238)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:634)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:418)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:725)

Jake loads jogl[2] and joal[3], both jnlp extensions and independent 
from Jake. Both of these extensions then load glugen-rt [4]. This 
diamond loading pattern is likely what causes this duplicate paths.

Cheers,
Omair

[1] http://www.bytonic.de/downloads/jake2_jogl11.jnlp
[2]http://download.java.net/media/jogl/builds/archive/jsr-231-1.x-webstart-current/jogl.jnlp
[3]http://download.java.net/media/joal/webstart/joal.jnlp
[4] http://download.java.net/media/gluegen/webstart/gluegen-rt.jnlp