[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-distro-pkg-dev
Subject:    [RFC] Netx: some native libraries are not found
From:       dbhole () redhat ! com (Deepak Bhole)
Date:       2010-06-30 22:04:41
Message-ID: 20100630220440.GD6610 () redhat ! com
[Download RAW message or body]

* Omair Majid <omajid at redhat.com> [2010-06-30 18:02]:
> 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

Fair enough! That is a valid case that we need to account for. Please
commit with the proposed modification.

Cheers,
Deepak


[prev in list] [next in list] [prev in thread] [next in thread]