[RFC] Netx: some native libraries are not found
dbhole at redhat.com
Wed Jun 30 15:04:41 PDT 2010
* 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]:
> >>>>There is a bug in the current version of Netx that fails to find
> >>>>some native libraries .
> >>>>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  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
> >>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)
> >> 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
> . Without that check we get a 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 and joal, both jnlp extensions and independent
> from Jake. Both of these extensions then load glugen-rt . This
> diamond loading pattern is likely what causes this duplicate paths.
>  http://www.bytonic.de/downloads/jake2_jogl11.jnlp
>  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.
More information about the distro-pkg-dev