<object type="application/x-java-applet" code="NoSuchFile.class">

            Console output follows.

            java version "1.6.0_20"
            OpenJDK Runtime Environment (IcedTea6 1.9.5) (6b20-1.9.5-0ubuntu1~10.04.1)
            OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
            net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:604)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
            Caused by: java.lang.NullPointerException
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:427)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
            ... 2 more
            Caused by:
            java.lang.NullPointerException
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:427)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:168)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:575)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:548)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:729)
            java.lang.NullPointerException
            at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:99)
            at sun.applet.AppletPanel.run(AppletPanel.java:380)
            at java.lang.Thread.run(Thread.java:636)
            java.lang.NullPointerException
            at sun.applet.AppletPanel.run(AppletPanel.java:430)
            at java.lang.Thread.run(Thread.java:636)

            Take a look at
            http://download.oracle.com/javase/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#object which
            shows how to use an object tag correctly. the object tag supports the attribute codebase, but not code.
            The "code" must be specified as a param element inside the object tag.

            Does the problem still occur after you fix the object element?

            Be that as it may, plugins shouldn't crash with null pointer exceptions no matter what input they
            receive. It's not just tasteless, the browser has to wait and eventually time out to discover it's not
            going to get an applet ID. That affects other browsing and it breaks the object tag fallback mechanism.

            > Does the problem still occur after you fix the object element?

            I don't have access to that machine at the moment, but I gave you a minimal test case. It's up to you to
            use it to investigate and sort out your code.

            tested on Firefox 6.0a1

            java version "1.6.0_18"
            OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-3)
            OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)

            Do you have a specific URL for us to test this with?

            --Andrew

            It is detailed here:

            http://slightlyrandombrokenthoughts.blogspot.ca/2011/03/oracle-java-applet-clipboard-injection.html

            Added clipboard reproducers (PR708)

            I am using ubuntu 12.04 with 64 bit machine. when i am using one website that is having applet run and
            process lots of havvy log files and a JFrame also populate.

            after logout or close my browser tab my system still using the same memory while processing the
            application/applet and that popup is not closed.

            but same thing i am doing in windows and popup open with Java program then is releasing the memory as
            well popup is closed.

            Memory only released when i will closing my browser completely. i think icedtea-web is not able to call
            applet destory funcation.

            please help me to resolve this.

            BR//
            Jitender Chauhan

            Later, I've discovered what the issue is and how to fix it, although I do not have a patch, because I
            don't know the code enough:
            Throughout the code, icedtea has calls to setLookAndFeel, that resets the current plaf to the system's
            plaf, that's gtk on unix.
            The problem lies in placement of those calls:
            Java documentation says that it's recommended to use setLookAndFeel as the first thing ever done with
            swing, before any other swing classes could be loaded, because failure to do so can have unexpected
            results.
            Icedtea code doesn't follow this, I saw something, not sure what part of the code is it, that before
            setting look and feel, it creates a security manager, the line that does that has the comment saying
            that it's side effect is to create a JWindow.
            That means that the component is created before setting look and feel, that's a violation of the rule
            stated above.
            I've made a simple test case that created a frame, then set a plaf to the native one, then creates and
            shows another frame.
            When I ran it with accessibility enabled, I saw that it hangs as javaws does.
            For comparison, removing the frame created before setLookAndFeel made it work.
            I think some things need to be reordered, and plaf reset should be done as early as possible before any
            swing class would get loaded, that would solve all problems.

            I am currently struggling to get swing/awk applications connected to the Ocra screen reader. I have
            updated my jre/lib/accessibility.properties to include
            assistive_technologies=org.GNOME.Accessibility.AtkWrapper and also made sure that the jre/lib/ext
            directory contains the java-atk-wrapper.jar and jni files, despite this I get no indication that the
            AtkWrapper gets initialized/used when I start swing or awt applications. This setup/configure issue
            delay me from starting to work on a fix for this bug. I will try recompile my java-atk-wrapper from
            upstream source and see if that help.

            Two quick questions:
            1) Are the java-atk-wrapper known to work in combination with openjdk-6?
            2) Are the java-atk-wrapper known to work in combination with gnome 3.0?

            Cheers, and have a great day
            Xerxes Rånby

            Ok I have reproduced this bug as described. I have also verified that javaws -viewer can start and work
            in combination with the java-atk-wrapper, and ocra, if I simply removed the setLookAndFeel lines inside
            the javaws and plugin source-code.

            I will start examine how to fix this bug and still have setLookAndFeel enabled.
            Cheers,
            Xerxes

            The attached patch removes all calls to UIManager.setLookAndFeel() after it is set once.

            I have not verified this, but the UI elements used by icedtea-web should still have the system look and
            feel since all icedtea-web UI should be associated with the main AppContext. If they dont, then that
            sounds like another bug to me (I suspect the UI associated with download progress bars might run into
            this). The target application/applet should be running in a separate AppContext and should get it's own
            look and feel (the default is metal).

            Note that extra/net/sourceforge/javaws/about/Main.java and
            netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java are separate applications and should not
            encounter the same problem.

            PR857: Don't set look and feel multiple times

            2014-03-03 Omair Majid <[email protected]>

            PR857
            * netx/net/sourceforge/jnlp/about/AboutDialog.java
            (run): Do not set look and feel.
            * netx/net/sourceforge/jnlp/runtime/Boot.java
            (main) <about>: Set look and feel before displaying dialog.
            * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
            (initialize): Set look and feel before any UI is created.
            * netx/net/sourceforge/jnlp/security/SecurityDialog.java
            (init): Do not set look and feel.
            (setSystemLookAndFeel): Removed.
            * netx/net/sourceforge/jnlp/security/policyeditor/PolicyEditor.java
            (createInstance): Do not set look and feel.
            * netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
            (showCertificateViewer): Do not set look and feel.
            (setSystemLookAndFeel): Removed.

            Thanks for considering this.

            Jiri, I saw that you are about to release 1.6.2. It would be good to strike this one off the list as it
            is still an issue for us. Here is an updated patch that adds LDFLAGS in all the relevant places, not
            just the main plugin target.

            Incidentally, I spot in the context that a bare 'ar' is being used. This needs to be fixed.

            Right you are, here's a better one.

            This creates a static IIORegistry (IIORegistry.getDefaultInstance) that scans the classpath for all the
            spi providers.
            At this moment the classpath does not seems to contain all the jars declared in the JNLP so the new
            providers are not discovered.

            In our JNLP application we use the jai_imageio-1.1-windows-i586.jar with the TIFF codec. Later during
            the process the ImageIO.read() on a tiff image fails.

            Workaround :
            Before trying to read an image a call to ImageIO.scanForPlugins() forces a scan of the classpath. It
            only has to be done once.

            java version "1.6.0_22"
            OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-1)
            OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

            new java.net.URLClassLoader(java.lang.reflect.Array.newInstance(java.lang.Class.forName("java.net.URL"),
            0));

            from Firefox chrome:// (privileged) generates a LiveConnectPermissionNeeded error in icedtea-web. This
            same code does not generate an exception in the old IcedTea LiveConnect/OJI plug-in, nor does it
            generate an exception in any of the Sun NPRuntime Java plug-ins.

            This prevents almost all Firefox extensions that use Java from working with IcedTea, and affects several
            thousand Zotero users.

            The Sun NPRuntime plug-in explicitly checks whether the origin is a chrome:// URI, and grants it
            enhanced privileges appropriately. AFAIK there's no reason IcedTea couldn't do this as well.

            See also:
            RedHat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=598519
            Launchpad: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/596688

            I get these funky debug output lines:
            preinit_plugindebug #1415351500042325 [thomas][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 07 10:11:40 CET
            2014][/builddir/build/BUILD/icedtea-w
            eb-1.5.1/plugin/icedteanp/IcedTeaPluginUtils.cc:1180] ITNPP Thread# 140018407193152, gthread
            0x7f5893419d20: plugin_debug_to_file: true
            , using /home/thomas/.config/icedtea-web/log/itw-cplugin-2014-11-07_10:11:40.41.log
            java.text.ParseException: Unparseable date: "Fr Nov 07 10:11:40 CET 2014"
            at java.text.DateFormat.parse(DateFormat.java:357)
            at net.sourceforge.jnlp.util.logging.headers.PluginMessage.<init>(PluginMessage.java:73)
            at net.sourceforge.jnlp.util.logging.JavaConsole.processPluginMessage(JavaConsole.java:523)
            at net.sourceforge.jnlp.util.logging.JavaConsole.access$1100(JavaConsole.java:87)
            at net.sourceforge.jnlp.util.logging.JavaConsole$13.run(JavaConsole.java:554)
            at java.lang.Thread.run(Thread.java:745)


            The log file /home/thomas/.config/icedtea-web/log/itw-javantx-2014-11-07_10:11:40.823.log is full with
            messages of these kind.

            makes the logging work correctly.

            I guess your defaule locales are somehting like de_DE.utf8
            and os some German-like date is going from plugin to java.

            I think I will just silence this exception, and if it ocure, the original value will br printed. (as
            date of even is going in as long)

            I iwll look into this and do try some workaround for upcoming release.

            For testing:

            Binaries from http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2016-January/034732.html

            May be useful.

            Thanx!

            You need to provide a recent log failure and your setting of LANG to move further with this.

            Any updates?

            Thanks

            IcedTea javaws fails to properly run the ILO4 remote console Java Web Start application.

            This app does run correctly with javaws shipped with the Oracle JDK.

            When ran using icedtea-web a window opens but is completely blank.

            In the logs is nothing bad. The application started fine. To fix this, I need to attach debugger. ==
            access to application or reproducer:(

            I can think of two ways to proceed:

            1. I somehow work out how to attach a debugger and send you what you need. I'm not a java developer, so
            this could be trick.

            2. I somehow work out how to give you access to my hardware. Given this would involve opening up my home
            network, it's not ideal :) will give it some thought though.

            As far as I know, it's not an open source app.

            Jnlp file is text file with instructions how to obntain and download the jar. In this case it was
            generated from some server on your internal network.

            This seems to be the jar file that the jnlp downloads.

            I guess missing lang/en/jirc_strings.xml is issue here.

            I can then see small window of application without content.


            When I fake the file, I got:
            127.0.0.1 - - [05/Apr/2018 09:58:42] "HEAD /iLO-jirc.jnlp HTTP/1.1" 200 -
            127.0.0.1 - - [05/Apr/2018 09:58:42] "HEAD /html/intgapp4_231.jar HTTP/1.1" 200 -
            127.0.0.1 - - [05/Apr/2018 09:58:44] code 400, message Bad request syntax
            ('\x16\x03\x03\x00\xab\x01\x00\x00\xa7\x03\x03Z\xc5\xd74^\xce\xee\xe7\xb0\xf3*\xed\xc0\x03j\x03B\xc7\x1d\xfc\xee\xdd!\xb7:\xfa\x15\x910\xba')
            127.0.0.1 - - [05/Apr/2018 09:58:44] "��Z��4^�����*��jB����!�:��0�" 400 -
            127.0.0.1 - - [05/Apr/2018 09:58:44] "GET /lang/en/jirc_strings.xml HTTP/1.1" 200 -


            (the jnlp and jar are already in cache), I got an exception:
            Write xml to/tmp/jirc_strings2b3bfac6.xmlcomplete
            Message after comp of webserver retrieval
            [Fatal Error] jirc_strings2b3bfac6.xml:1:1: Content is not allowed in prolog.
            org.xml.sax.SAXParseException; systemId: file:/tmp/jirc_strings2b3bfac6.xml; lineNumber: 1;
            columnNumber: 1; Content is not allowed in prolog.
            at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)
            at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
            at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:205)
            at com.hp.ilo2.intgapp.locinfo.initLocStrings(locinfo.java:499)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:113)
            at net.sourceforge.jnlp.runtime.AppletEnvironment$2.run(AppletEnvironment.java:198)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
            at java.awt.EventQueue.access$500(EventQueue.java:97)
            at java.awt.EventQueue$3.run(EventQueue.java:709)
            at java.awt.EventQueue$3.run(EventQueue.java:703)
            at java.security.AccessController.doPrivileged(Native Method)
            at
            java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
            [jvanek][ITW-JAVAWS][ERROR_DEBUG][Thu Apr 05 09:58:45 CEST
            2018][net.sourceforge.jnlp.runtime.AppletEnvironment.startApplet(AppletEnvironment.java:207)] NETX
            Thread# 3e96ba4f, name Integrated Remote Console
            java.lang.reflect.InvocationTargetException
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
            at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
            at net.sourceforge.jnlp.runtime.AppletEnvironment.startApplet(AppletEnvironment.java:191)
            at net.sourceforge.jnlp.Launcher.launchApplet(Launcher.java:652)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:943)
            Caused by: java.lang.NullPointerException
            at com.hp.ilo2.virtdevs.virtdevs.init(virtdevs.java:137)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:115)
            at net.sourceforge.jnlp.runtime.AppletEnvironment$2.run(AppletEnvironment.java:198)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
            at java.awt.EventQueue.access$500(EventQueue.java:97)
            at java.awt.EventQueue$3.run(EventQueue.java:709)
            at java.awt.EventQueue$3.run(EventQueue.java:703)
            at java.security.AccessController.doPrivileged(Native Method)
            at
            java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

            This is still caused by the jirc_strings2b3bfac6.xml file being not xml....
            Can you provide file of /lang/en/jirc_strings.xml?
            Maybe the xml is wrongly located or ITW search for it on wrong path?

            More faking of jirc_strings.xml had some sucess. The xml properties were loaded, but later come death
            by:
            Exception: java.io.FileNotFoundException: /home/jvanek/.java/hp.properties (No such file or directory)
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.util.logging.FileLog.getFileName(FileLog.java:112)] NETX Thread# 3283452c,
            name Output controller consumer daemon Attempting to log into:
            /home/jvanek/.config/icedtea-web/log/itw-clienta-2018-04-05_10:22:05.287.log
            Trying to select locale: en_US
            Started Retrieving parameters from ILO..
            chk getPort: 8000
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:183)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selecting proxy for: https://localhost:8000/json/rc_info
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.browser.BrowserAwareProxySelector.getFromBrowser(BrowserAwareProxySelector.java:222)]
            NETX Thread# 1321c311, name AWT-EventQueue-1 Browser selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:212)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:183)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selecting proxy for: socket://localhost:8000
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.browser.BrowserAwareProxySelector.getFromBrowser(BrowserAwareProxySelector.java:222)]
            NETX Thread# 1321c311, name AWT-EventQueue-1 Browser selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:212)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selected proxies: [DIRECT]
            javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
            at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
            at
            sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
            at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
            at com.hp.ilo2.intgapp.jsonparser.getJSONRequest(jsonparser.java:185)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:107)
            at net.sourceforge.jnlp.runtime.AppletEnvironment$2.run(AppletEnvironment.java:198)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
            at java.awt.EventQueue.access$500(EventQueue.java:97)
            at java.awt.EventQueue$3.run(EventQueue.java:709)
            at java.awt.EventQueue$3.run(EventQueue.java:703)
            at java.security.AccessController.doPrivileged(Native Method)
            at
            java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
            Message from beginning of initLocStrings
            langStr received:en
            lolcalized xml file shoudl be:lang/en/jirc_strings.xml
            Creating/tmp/jirc_stringsfbe450.xml...
            try localize file from webserver..
            trying to retreive webser localize file:http://localhost:8000/lang/en/jirc_strings.xml
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:183)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selecting proxy for: http://localhost:8000/lang/en/jirc_strings.xml
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.browser.BrowserAwareProxySelector.getFromBrowser(BrowserAwareProxySelector.java:222)]
            NETX Thread# 1321c311, name AWT-EventQueue-1 Browser selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:212)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:183)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selecting proxy for: socket://localhost:8000
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.browser.BrowserAwareProxySelector.getFromBrowser(BrowserAwareProxySelector.java:222)]
            NETX Thread# 1321c311, name AWT-EventQueue-1 Browser selected proxies: [DIRECT]
            [jvanek][ITW-JAVAWS][MESSAGE_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:212)] NETX Thread#
            1321c311, name AWT-EventQueue-1 Selected proxies: [DIRECT]
            Write xml to/tmp/jirc_stringsfbe450.xmlcomplete
            Message after comp of webserver retrieval
            Message after completion of initLocStrings
            [jvanek][ITW-JAVAWS][ERROR_DEBUG][Thu Apr 05 10:22:05 CEST
            2018][net.sourceforge.jnlp.runtime.AppletEnvironment.startApplet(AppletEnvironment.java:207)] NETX
            Thread# 56234f11, name Integrated Remote Console
            java.lang.reflect.InvocationTargetException
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1349)
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
            at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
            at net.sourceforge.jnlp.runtime.AppletEnvironment.startApplet(AppletEnvironment.java:191)
            at net.sourceforge.jnlp.Launcher.launchApplet(Launcher.java:652)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:943)
            Caused by: java.lang.NullPointerException
            at com.hp.ilo2.virtdevs.virtdevs.init(virtdevs.java:137)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:115)
            at net.sourceforge.jnlp.runtime.AppletEnvironment$2.run(AppletEnvironment.java:198)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
            at java.awt.EventQueue.access$500(EventQueue.java:97)
            at java.awt.EventQueue$3.run(EventQueue.java:709)
            at java.awt.EventQueue$3.run(EventQueue.java:703)
            at java.security.AccessController.doPrivileged(Native Method)
            at
            java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)


            Funny is the NPE exception on closing of ITW. BUt I gues its arch-cause is the bad loading.
            I think it is bug in HP console - using some oracle-javaws implementation specific issue.
            Can you conenct me with HP developers? I will be happy to debug it with them and to avoid decompiling
            the library.

            Unfortunately I have no connection with the HP developers, nor any means to contact them, I am afraid.
            The only thing I've found is this:

            https://developer.hpe.com/platform/ilo-restful-api/home

            which seems to be a developer portal for a REST API that HP build on top of ILO.

            https://community.hpe.com/t5/ProLiant-Servers-ML-DL-SL/HP-ILO-remote-console-web-start-fails-with-OpenJDK-and-IcedTea/td-p/7015396

            Here is the jirc_strings.xml file.

            So for some reason:

            127.0.0.1 - - [05/Apr/2018 09:50:27] "GET /lang/en/jirc_strings.xml HTTP/1.1" 404 -

            The file is not downlaoded. The :

            (the jnlp and jar are already in cache), I got an exception:
            Write xml to/tmp/jirc_strings2b3bfac6.xmlcomplete
            Message after comp of webserver retrieval
            [Fatal Error] jirc_strings2b3bfac6.xml:1:1: Content is not allowed in prolog.
            org.xml.sax.SAXParseException; systemId: file:/tmp/jirc_strings2b3bfac6.xml; lineNumber: 1;
            columnNumber: 1; Content is not allowed in prolog.

            Is caused by server returning some 404 message together with the 404 code, and app is trying to parse it
            as xml.


            How have you get the file?


            The call is from inside the client application, not from ITW. So maybe they are using codebase/docbase
            somehow to get th full url, and go wrong?


            THis will fight the windmills unless I have a way how to reproduce:(

            wget http://192.168.1.153/lang/en/jirc_strings.xml

            after starting the web console (using the oracle java web start).

            I believe this is strictly an IcedTea-Web issue because not only does it work with Oracle's javaws, if I
            point itweb-settings to the Oracle JRE, it's broken there too. Unfortunately you can't use Oracle's
            javaws with OpenJDK.

            In terms of reproducing it without hardware, I was able to point it at localhost and have it accept
            jirc_strings.xml as well as rc_info but it just sits there without error before any window appears. Not
            too surprising given the nature of it.

            I'd love to help further but I'm leaving the company next week so I will no longer have access to this
            hardware.

            Here You go (:
            No `/json/*` since I can't/don't know how to retrieve them.

            I tired your command-like run, and also via http server served.
            In server I have log of:

            127.0.0.1 - - [15/Nov/2018 16:05:03] "HEAD /iLO-jirc.jnlp HTTP/1.1" 200 -
            127.0.0.1 - - [15/Nov/2018 16:05:03] "GET /iLO-jirc.jnlp HTTP/1.1" 200 -
            127.0.0.1 - - [15/Nov/2018 16:05:03] "HEAD /intgapp3_231.jar HTTP/1.1" 200 -
            127.0.0.1 - - [15/Nov/2018 16:05:03] "GET /intgapp3_231.jar HTTP/1.1" 200 -
            127.0.0.1 - - [15/Nov/2018 16:05:06] code 400, message Bad request syntax
            ('\x16\x03\x03\x00\x8f\x01\x00\x00\x8b\x03\x03[\xed\x8b"]\x96\x03_=\xfc\x96')
            127.0.0.1 - - [15/Nov/2018 16:05:06] "��[�"]�_=��" 400 -

            and client:
            javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
            at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
            at
            sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
            at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
            at com.hp.ilo2.intgapp.jsonparser.getJSONRequest(jsonparser.java:185)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:105)


            Some setup is missing. Please provide working and tested reproducer :( What more, a linux one. There is
            no windows machine several hundred of kilometres around me I would be able to use.

            Take two: Here You go (:
            Instructions inside.

            PS: In the GNU/Linux extensions is nothing :P
            $ file HpqKbHook-199efdc0.dll
            HpqKbHook-199efdc0.dll: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked,
            BuildID[sha1]=bff74e2b3ce951ee1c730c32e6f085a5be2263c3, stripped

            [1]
            javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
            at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
            at
            sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
            at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
            at com.hp.ilo2.intgapp.jsonparser.getJSONRequest(jsonparser.java:185)
            at com.hp.ilo2.intgapp.intgapp.init(intgapp.java:105)

            Just visualizing our goal.

            Reproduction: Go to a site with an applet, click Cancel to the security check, after it errors, "Click
            here for errors" link in the applet area.

            Firefox 40.0 Mozilla Firefox for Mint mint - 1.0
            1.5-1ubuntu1

            Current error wording:
            "The folloing exception has occured. For more information, try to launch the browser from the command
            line and examine the output.
            For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the
            steps described there on how to obtain necessary information to file bug
            Additional information may be available in the console or logs. Even more information is available if
            debugging is enabled."

            Corrected:
            The following exception has occurred. For detailed information, try launching the browser from the
            command line and examine the output.
            For additional information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the
            steps described on how to obtain the necessary information to search for and file a bug.
            Additional information may be available in the console or log files. Extended information is available
            if debugging is enabled.

            Nearly no of the developers in English native. Language patches are more then welcomed.

            Due to lack of time, without patch to Messages.properties this will be clsoed as wontfix.

            As a minimum, files with user-visible text should at least be spell-checked.

            org.apache.commons.validator.ValidatorException: java.lang.ClassNotFoundException:
            net.java.dev.genesis.ui.BasicValidator
            at org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:624)
            at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:530)
            at org.apache.commons.validator.Field.validateForRule(Field.java:796)
            at org.apache.commons.validator.Field.validate(Field.java:876)
            at org.apache.commons.validator.Form.validate(Form.java:288)
            at org.apache.commons.validator.Validator.validate(Validator.java:351)
            at net.java.dev.genesis.ui.ValidationUtils.validate(ValidationUtils.java:198)
            at net.java.dev.genesis.ui.ValidationUtils.validate(ValidationUtils.java:181)
            at net.java.dev.genesis.ui.controller.DefaultFormController.invokeAction(DefaultFormController.java:788)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:601)
            ......
            at com.sun.proxy.$Proxy17.invokeAction(Unknown Source)
            at net.java.dev.genesis.ui.binding.AbstractBinder.invokeAction(AbstractBinder.java:587)
            at net.java.dev.genesis.ui.binding.AbstractBinder.invokeFormAction(AbstractBinder.java:781)
            at
            net.java.dev.genesis.ui.swing.components.AbstractComponentBinder$ComponentBoundAction$1.actionPerformed(AbstractComponentBinder.java:353)
            at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
            at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
            at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
            at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
            at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
            at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:208)
            at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1661)
            at javax.swing.JComponent.processKeyBinding(JComponent.java:2870)
            at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:306)
            at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:250)
            at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2962)
            at javax.swing.JComponent.processKeyBindings(JComponent.java:2954)
            at javax.swing.JComponent.processKeyEvent(JComponent.java:2833)
            at java.awt.Component.processEvent(Component.java:6282)
            at java.awt.Container.processEvent(Container.java:2229)
            at java.awt.Component.dispatchEventImpl(Component.java:4861)
            at java.awt.Container.dispatchEventImpl(Container.java:2287)
            at java.awt.Component.dispatchEvent(Component.java:4687)
            at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1895)
            at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:762)
            at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1027)
            at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:899)
            at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:727)
            at java.awt.Component.dispatchEventImpl(Component.java:4731)
            at java.awt.Container.dispatchEventImpl(Container.java:2287)
            at java.awt.Window.dispatchEventImpl(Window.java:2719)
            at java.awt.Component.dispatchEvent(Component.java:4687)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
            at java.awt.EventQueue.access$200(EventQueue.java:103)
            at java.awt.EventQueue$3.run(EventQueue.java:688)
            at java.awt.EventQueue$3.run(EventQueue.java:686)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
            at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
            at java.awt.EventQueue$4.run(EventQueue.java:702)
            at java.awt.EventQueue$4.run(EventQueue.java:700)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

            IcedTea-Web Plugin (using IcedTea-Web 1.1pre+r04459b8baed4)

            Mozilla Firefox 3.6.13, Copyright (c) 1998 - 2010 mozilla.org

            OpenJDK Runtime Environment (IcedTea6 1.11pre+r0ca79255e13e) (Ubuntu build 1.6.0_22-b22)
            OpenJDK Server VM (build 20.0-b10, mixed mode)


            Testcase:
            http://download.oracle.com/javase/tutorial/deployment/applet/examples/dist/applet_InvokingAppletMethodsFromJavaScript/AppletPage.html

            Expected:
            The Math applet displays the following results on the web page when the number a = 0 and b = 5:

            Results of JavaScript to Java Communication

            Hello John Doe

            a = 0 ; b = 5

            Sum: 5

            Numbers in range array: [ 0, 1, 2, 3, 4, 5 ]

            Today's date is: 1/13/09 10:12 AM // shows current date

            What happened:
            no output, and browser lock-up and becomes unresponsive to navigation button clicks.

            Errors on console:
            java version "1.6.0_22"
            OpenJDK Runtime Environment (IcedTea6 1.11pre+r0ca79255e13e) (Ubuntu build 1.6.0_22-b22)
            OpenJDK Server VM (build 20.0-b10, mixed mode)
            net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:624)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:568)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:839)
            Caused by: java.lang.NullPointerException
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:608)
            ... 2 more
            Caused by:
            java.lang.NullPointerException
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:608)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:568)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:839)
            java.lang.NullPointerException
            at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:101)
            at sun.applet.AppletPanel.run(AppletPanel.java:380)
            at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:71)
            at java.lang.Thread.run(Thread.java:679)
            java.lang.NullPointerException
            at sun.applet.AppletPanel.run(AppletPanel.java:430)
            at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:71)
            at java.lang.Thread.run(Thread.java:679)
            Exception in thread "Thread-12" java.lang.NullPointerException
            at sun.applet.PluginAppletViewer$5.run(PluginAppletViewer.java:1653)
            at java.lang.Thread.run(Thread.java:679)
            net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:624)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:568)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:839)
            Caused by: java.lang.NullPointerException
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:608)
            ... 2 more
            Caused by:
            java.lang.NullPointerException
            at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:608)
            at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:568)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:839)
            java.lang.NullPointerException
            at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:101)
            at sun.applet.AppletPanel.run(AppletPanel.java:380)
            at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:71)
            at java.lang.Thread.run(Thread.java:679)
            java.lang.NullPointerException
            at sun.applet.AppletPanel.run(AppletPanel.java:430)
            at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:71)
            at java.lang.Thread.run(Thread.java:679)

            It seems there are some Firefox extensions relying (like quickjava) on a java string occurrence in a
            plugin name - because the PLUGIN_NAME returns the IcedTea NPR Web Browser Plugin ... the extension
            thinks there's no java installed. Olny one think prevents me to write a patch is - I don't know if we
            can use copyrighted name like java in icedtea plugin name.

            We used to describe GNU Classpath as 'a GNU project to create free core class libraries for use with
            virtual machines and compilers for the java programming language'.

            So 'IcedTea NPR Web Browser Plugin for the Java programming language' may be possible.

            BrowserAwareProxySelector throws IllegalArgument, if no socks proxy is configured.


            Steps to reproduce
            ------------------
            * Configure a http proxy but no socks proxy in Firefox
            * Go to https://stendhalgame.org, create an account and click on your character

            Excepted result
            ---------------

            A direct connection should be used and the game should start.

            Actual result
            -------------

            ERROR [AWT-EventQueue-1] LoginDialog.java ( 457) - unable to connect to server stendhalgame.org:32160
            java.lang.IllegalArgumentException: hostname can't be null
            java.net.InetSocketAddress.<init>(InetSocketAddress.java:139)
            net.sourceforge.jnlp.browser.BrowserAwareProxySelector.
            getFromBrowserConfiguration(BrowserAwareProxySelector.java:274)
            net.sourceforge.jnlp.browser.BrowserAwareProxySelector.
            getFromBrowser(BrowserAwareProxySelector.java:187)
            net.sourceforge.jnlp.runtime.JNLPProxySelector.
            select(JNLPProxySelector.java:208)
            marauroa.client.ClientFramework.discoverProxy(ClientFramework.java:188)

            Can you build from source and confirm? Or is there another test case I can use to check this myself?

            With packed resources, the file extension pack.gz or gz is appended, regardless of whether they already
            have it. I think you should save the resource with the original filename, as with unpacked resources.
            There can be no naming conflicts after unpacking, since different cache directories are used for the
            packed and unpacked variants.
            Enclosed a patch, which ensures exactly.

            ICEDTEAPLUGIN_DEBUG=true firefox 2>&1 | tee plugin.log
            http://paste.pocoo.org/show/572638/
            Java SE plugin logs
            http://paste.pocoo.org/show/572718/

            I am attaching a fresh plugin.log, obtained using the following command:
            ICEDTEAPLUGIN_DEBUG=true firefox 2>&1 | tee plugin.log

            I am also attaching, as the last post suggests, all of the log files in the ~/.icedtea/log folder. Let
            me know if you need any other logs or information.

            This attachment contains the plugin.log and the contents of the ~/.icedtea/log folder after running the
            OANDA fxTrade application, and letting it hang at 40%. I then closed Firefox after about 1 minute.

            --- icedtea-web-1.5.orig/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java
            +++ icedtea-web-1.5/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java
            @@ -290,7 +290,7 @@ public class ManifestAttributesChecker {

            if (usedUrls.size() == 1) {
            if (UrlUtils.equalsIgnoreLastSlash(usedUrls.toArray(new URL[0])[0], codebase)
            - && UrlUtils.equalsIgnoreLastSlash(usedUrls.toArray(new URL[0])[0], documentBase)) {
            + || UrlUtils.equalsIgnoreLastSlash(usedUrls.toArray(new URL[0])[0], documentBase)) {
            //all resoources are from codebase or document base. it is ok to proceeed.
            OutputController.getLogger().log("All applications resources (" + usedUrls.toArray(new URL[0])[0] + ")
            are from codebas/documentbase " + codebase + "/" + documentBase + ", skipping
            Application-Library-Allowable-Codebase Attribute check.");
            return;

            Again this behaviour is only native on IcedTea, other platforms and OSs do not get this issue. For
            example it runs fine on Linux Oracle Java

            Applet code consists of two signed .jar files and works on a non-defined codebase (any server).
            JNLP file and manifests can be found in the thread of Bug #3350 if needed

            To reach this point, developer has to workaround the Case 3350 by using codebase="." in the jnlp file,
            so that the code starts loading.

            I am running default (empty) deployment.properties, except logging and console options and I am clearing
            cache between each run.

            So Jiri tested the code as well and gets the same behaviour as I do:

            I have an error check point in the beginning of the code.
            The applet tries to load a class from the second .jar and fails. My code catches the exception and exits
            prematurely with an user-friendly error message.

            If I disable the exception catching (in order to check the error in the clear), I get the following in
            the console:

            java.lang.reflect.InvocationTargetException
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1321)
            at java.awt.EventQueue.invokeAndWait(EventQueue.java:1296)
            at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
            at net.sourceforge.jnlp.runtime.AppletEnvironment.startApplet(AppletEnvironment.java:191)
            at net.sourceforge.jnlp.Launcher.launchApplet(Launcher.java:655)
            at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:939)
            Caused by: java.lang.IllegalStateException: zip file closed
            at java.util.zip.ZipFile.ensureOpen(ZipFile.java:669)
            at java.util.zip.ZipFile.getEntry(ZipFile.java:309)
            at java.util.jar.JarFile.getEntry(JarFile.java:240)
            at java.util.jar.JarFile.getJarEntry(JarFile.java:223)
            at sun.misc.JarIndex.getJarIndex(JarIndex.java:137)
            at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:877)
            at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:869)
            at java.security.AccessController.doPrivileged(Native Method)
            at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:868)
            at sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:819)
            at sun.misc.URLClassPath$3.run(URLClassPath.java:565)
            at sun.misc.URLClassPath$3.run(URLClassPath.java:555)
            at java.security.AccessController.doPrivileged(Native Method)
            at sun.misc.URLClassPath.getLoader(URLClassPath.java:554)
            at sun.misc.URLClassPath.getLoader(URLClassPath.java:519)
            at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:484)
            at sun.misc.URLClassPath.getResource(URLClassPath.java:238)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:365)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.access$1701(JNLPClassLoader.java:103)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1666)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader$5.run(JNLPClassLoader.java:1663)
            at java.security.AccessController.doPrivileged(Native Method)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.findClass(JNLPClassLoader.java:1662)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1699)
            at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1498)
            at Kemtrak.start(Kemtrak.java:915)
            at net.sourceforge.jnlp.runtime.AppletEnvironment$2.run(AppletEnvironment.java:199)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
            at java.awt.EventQueue.access$500(EventQueue.java:97)
            at java.awt.EventQueue$3.run(EventQueue.java:709)
            at java.awt.EventQueue$3.run(EventQueue.java:703)
            at java.security.AccessController.doPrivileged(Native Method)
            at
            java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)


            The code that does not catch the exception is uploaded in the usual location that Jiri knows. So you can
            run it.

            I wanted to see if the code fails because it cannot load any non-main class or if the problem was only
            when loading a class from the second .jar file.
            I commented the line away (Line 915) and the code still fails on the next line that loads a class (Line
            1037) where it tries to load a class from the first (main) . jar file.
            So as far as I see it seems it cannot load any non-main classes at all.

            looking to it. The Kemtrak does:

            localObject3 = (java.net.JarURLConnection)localURL.openConnection();
            java.util.jar.JarFile localJarFile = ((java.net.JarURLConnection)localObject3).getJarFile();
            str9 = localJarFile.getName();
            i3 = localJarFile.size();
            localJarFile.close();
            ...
            org.freixas.jcalendar.JCalendarCombo localJCalendarCombo = new
            org.freixas.jcalendar.JCalendarCombo(java.util.Calendar.getInstance(), Locale.getDefault(), 1, true,
            "HH:mm:ss");
            Do you mind to try to remove localJarFile.close(); ?


            Anyway this is interesting issue. If my bet is correct, then itw needs soem fix, of mayb java's
            JarURLConnection needs some fix. (first is more appropriate).

            In all cases the fix will not be easy.

            (In reply to JiriVanek from comment #1)
            > Hi!
            >
            > looking to it. The Kemtrak does:
            >
            > localObject3 = (java.net.JarURLConnection)localURL.openConnection();
            > java.util.jar.JarFile localJarFile =
            > ((java.net.JarURLConnection)localObject3).getJarFile();
            > str9 = localJarFile.getName();
            > i3 = localJarFile.size();
            > localJarFile.close();
            > ...
            > org.freixas.jcalendar.JCalendarCombo localJCalendarCombo = new
            > org.freixas.jcalendar.JCalendarCombo(java.util.Calendar.getInstance(),
            > Locale.getDefault(), 1, true, "HH:mm:ss");
            > Do you mind to try to remove localJarFile.close(); ?

            Hi,
            This is line 900, a part where I open a tentative connection to the jar file just to see if it exists
            (error control in case it is not there). Connection is/was closed in the end as it is not used anywhere
            (I thought it was good practice to close the connection when finished). After code confirms file exists,
            class is loaded on Line 915 (and it was giving the exception there).

            As soon as I comment away line 900, whole code starts working!!!
            Wow, that was an impressive catch you made.

            >
            >
            > Anyway this is interesting issue. If my bet is correct, then itw needs soem
            > fix, of mayb java's JarURLConnection needs some fix. (first is more
            > appropriate).

            I am just thinking here: If it was Java's JarURLConnection problem, wouldn't that mean that the applet
            would fail in other implementations as well ?(which it does not).

            In any case the code with the localJarFile.close(); commented away is in the usual place and you can see
            it running now :)

            Still some warning messages come up in the console but they are not "fatal" anyway.


            >
            > In all cases the fix will not be easy.


            Should I leave the code with that line commented away? Is it OK if I do *not* close that connection? I
            closed the connection after using it because I thought it was good practice. And because Java does not
            complain, except on the IcedTea case, the code has been running like that for years now. Would it create
            any problems leaving the connection open? Or it closes when the applet exits?

            Thanks!

            good!

            >
            > (In reply to JiriVanek from comment #1)
            > > Hi!
            ...
            >
            > I am just thinking here: If it was Java's JarURLConnection problem, wouldn't
            > that mean that the applet would fail in other implementations as well
            > ?(which it does not).

            Other implementations means proprietary Oracle javaws. HAve you tried on IBM javaws? They may even be
            returning different stream then JarURLConnection. This is not safe retyping...

            Last time I was looking into oracle plugin (and so a bit also to javaws) there was a lot of copypasted
            code from Openjdk. With small tweeks. MAybe Tehre was also JarURLConnection overwritten.
            That something ITW can not afford.


            >
            > In any case the code with the localJarFile.close(); commented away is in the
            > usual place and you can see it running now :)
            >
            > Still some warning messages come up in the console but they are not "fatal"
            > anyway.

            thank you for uplading the app again. As for wornings, I think you can ignore happily all http and
            bundle related.


            however the java.lang.ClassCastException: java.awt.Frame cannot be cast to javax.swing.JFrame is worty
            of thinking about. This is not first app having this problem:

            topFrame = ((javax.swing.JFrame)javax.swing.SwingUtilities.getWindowAncestor(this));

            If you can, try to cast it to something more deepr in inheritance. awt.Frame should be fine.

            >
            >
            > >
            > > In all cases the fix will not be easy.
            >
            >
            > Should I leave the code with that line commented away? Is it OK if I do
            > *not* close that connection? I closed the connection after using it because
            > I thought it was good practice. And because Java does not complain, except
            > on the IcedTea case, the code has been running like that for years now.
            > Would it create any problems leaving the connection open? Or it closes when
            > the applet exits?

            Dont forget we are no longer speaking about applet. But about javaws application. So having this opened
            will not harm to much (unlike applet, after closgin javaws, its done).

            Anyway - I would recommend you to get rid of those calls at all.

            If you simply call Class.forName on any class from jcalendar, you will immediately know if it is
            correctly downloaded and usable. No need to bother with urlstreams.
            Also when you have already have localURL = new java.net.URL("jar", "", cbase + "jcalendar.jar!/"); you
            can simply ocnvert it to File and you will have its size.


            Still - note - this may be serious issue in itw. Please fix your application so it works on all desired
            platforms, but dont close this issue. I will creeate autoamted reproducer (so you can remove the app you
            exposed for me) and debug internals of itw...

            happy your app runs fine now. Please get rid of that jarurl connection :)


            >
            > Thanks!

            np!

            Reproduced issue PR3351

            * tests/reproducers/signed/Kemtrakpro/resources/Kemtrak_javaws.jnlp: jnlp file to test also javaws (next
            to applet) behavior
            * tests/reproducers/signed/Kemtrakpro/srcs/Kemtrak.java: added code to reproduce issue
            * tests/reproducers/signed/Kemtrakpro/testcases/KemtrakTests.java: added testcases for applet to close
            jar and try to load class again. added same testcases for javaws. Added testcase for plain java run to
            prove underlying jdk is not guilty
            * tests/reproducers/signed/jcalendar/srcs/jcalendar.java: small modification to add distinguish call
            inside.

            If you insists on your jarchecks, you can make them run in ITW in following way:


            localObject3 = (java.net.JarURLConnection)localURL.openConnection();
            java.util.jar.JarFile localJarFile = ((java.net.JarURLConnection)localObject3).getJarFile();
            str9 = localJarFile.getName();
            i3 = localJarFile.size();
            insert here [1]
            localJarFile.close
            ...
            org.freixas.jcalendar.JCalendarCombo localJCalendarCombo = new
            org.freixas.jcalendar.JCalendarCombo(java.util.Calendar.getInstance(), Locale.getDefault(), 1, true,
            "HH:mm:ss");


            [1]
            try{
            org.freixas.jcalendar.JCalendarCombo localJCalendarCombo = new
            org.freixas.jcalendar.JCalendarCombo(java.util.Calendar.getInstance(), Locale.getDefault(), 1, true,
            "HH:mm:ss");
            } catch (Exeption ex){
            Log.info(ex)
            }


            By calling the jcalendar jar *BEFORE* closing it, is causing the counter of connections to open for ITW
            to ++ (so to 2) then closing will reduce to 1, and so it keeps open.


            I will try to fix this in ITW.

            Of ocurse first call to jcalendar may fail (that why exception is ony info) the call which meters is the
            second one. So keep it.

            (In reply to JiriVanek from comment #3)
            > (In reply to stefan from comment #2)
            > > Hi, I'll break you the good news first, we have the code working!!
            > > Still some warnings in the terminal window but it runs at least.
            > > See below
            >
            > good!
            >
            > >
            > > (In reply to JiriVanek from comment #1)
            > > > Hi!
            > ...
            > >
            > > I am just thinking here: If it was Java's JarURLConnection problem, wouldn't
            > > that mean that the applet would fail in other implementations as well
            > > ?(which it does not).
            >
            > Other implementations means proprietary Oracle javaws. HAve you tried on IBM
            > javaws? They may even be returning different stream then JarURLConnection.
            > This is not safe retyping...
            >
            > Last time I was looking into oracle plugin (and so a bit also to javaws)
            > there was a lot of copypasted code from Openjdk. With small tweeks. MAybe
            > Tehre was also JarURLConnection overwritten.
            > That something ITW can not afford.
            >
            >
            > >
            > > In any case the code with the localJarFile.close(); commented away is in the
            > > usual place and you can see it running now :)
            > >
            > > Still some warning messages come up in the console but they are not "fatal"
            > > anyway.
            >
            > thank you for uplading the app again. As for wornings, I think you can
            > ignore happily all http and bundle related.
            >
            >
            > however the java.lang.ClassCastException: java.awt.Frame cannot be cast to
            > javax.swing.JFrame is worty of thinking about. This is not first app having
            > this problem:
            >
            > topFrame =
            > ((javax.swing.JFrame)javax.swing.SwingUtilities.getWindowAncestor(this));
            >
            > If you can, try to cast it to something more deepr in inheritance. awt.Frame
            > should be fine.

            Fixed! Thank you very much for catching this!

            >
            > >
            > >
            > > >
            > > > In all cases the fix will not be easy.
            > >
            > >
            > > Should I leave the code with that line commented away? Is it OK if I do
            > > *not* close that connection? I closed the connection after using it because
            > > I thought it was good practice. And because Java does not complain, except
            > > on the IcedTea case, the code has been running like that for years now.
            > > Would it create any problems leaving the connection open? Or it closes when
            > > the applet exits?
            >
            > Dont forget we are no longer speaking about applet. But about javaws
            > application. So having this opened will not harm to much (unlike applet,
            > after closgin javaws, its done).
            >
            > Anyway - I would recommend you to get rid of those calls at all.
            >
            > If you simply call Class.forName on any class from jcalendar, you will
            > immediately know if it is correctly downloaded and usable. No need to bother
            > with urlstreams.
            > Also when you have already have localURL = new java.net.URL("jar", "", cbase
            > + "jcalendar.jar!/"); you can simply ocnvert it to File and you will have
            > its size.
            >

            Just for the sake of the discussion, that would not work. File.length() from non-local URL/URIs returns
            0 size . If the file size is needed, opening an http or jar connection is recommended, that's why I had
            to do it like this in the initial code.
            However this is a redundant check (jar file size) and I removed it. I can always catch the
            jar-file-not-exists-error by catching the failure of loading a class from it. I can't be 100% sure that
            the class does not load because the jar file is not there (it could be some permission problem) but it
            is the most probable reason, so I recoded using that and got rid of the jar connection.
            Thanks for the tip anyway!

            >
            >
            > Still - note - this may be serious issue in itw. Please fix your application
            > so it works on all desired platforms, but dont close this issue. I will
            > creeate autoamted reproducer (so you can remove the app you exposed for me)
            > and debug internals of itw...
            >
            > happy your app runs fine now. Please get rid of that jarurl connection :)
            >
            >
            >
            >
            >
            >
            > >
            > > Thanks!
            >
            > np!

            The problem I'm experiencing is IcedTea fails to load an applet that has multiple JAR files where other
            classes and resources are stored (a base class library).

            --- Description ---

            I'm using a Virtual PC image of Linux-Fedora 13 with the stock OpenJDK/IcedTea runtime to launch a
            simple applet within the Firefox web browser.

            There's multiple scenarios where the web page fails to load the applet. Note: All scenarios use the HTML
            "EMBED" parameter to embed the applet within the web page.

            Scenario 1 and 2: Launching an applet which uses classes from another JAR file (a base class library)
            fails to load. This fails with or without the use of a JNLP file specified within the HTML "EMBED" tag.

            Scenario 3 and 4: Launching an applet where the base classes are all packaged into 1 "main" JAR file.
            Launching the applet with the JNLP file fails; whereas launching the applet without the JNLP file
            successfully loads it into the web page.

            --- Examples and Source Code ---

            I've created an example web page that demonstrates this error (source code is also provided) located
            here:

            http://dale.dns4me.com:8003/Bug_Reports/7_IcedTea_Libs/index.htm

            I will add test for this, but look like JDK issue and probably not fixible in age of jdk8

            I'm using icedtea-web-1.1.4, i. e. the icedtea-web-1.1.4-3.fc16.x86_64.rpm in Fedora 16, with the
            Firefox browser.

            The applet in question gets started properly via HTTP, regardless if using a proxy for HTTP or not. But
            shortly after the applet was started, it tries to open a TCP connection. This works, if the browser is
            configured for direct internet access, i. e. without a proxy.

            When configuring the browser to use a proxy for HTTP, HTTPS and GOPHER, but
            leaving the SOCKS proxy configuration empty (i. e. when there is no SOCKS proxy needed and available),
            the applet is not able to open this very same TCP connection, but fails instead.

            I've created a small shell script to run javaws (from icedtea-web) with the -verbose option and
            configured Firefox to use this script instead of /usr/bin/javaws. With this setup I created two log
            files, using the applet with and without a configured proxy, as described above. I'll attach these logs.

            The interesting part is after the line that says "Selecting proxy for:
            socket://platane-irmc.mgt.folz.de:80": When having no proxy for HTTP, then it says "Selected proxies:
            [DIRECT]", but when having a valid proxy for HTTP and an empty proxy configuration for SOCKS, it says
            nothing. This is the point where the TCP connection of the applet fails and the applet complains with an
            alert box containing: "java.lang.illegalArgumentException: port out of range:-2147483648"

            So, icedtea-web's javaws tries to use a SOCKS proxy when there is none configured, but when proxy
            configurations exist for other protocols. This is a bad idea, since there is no other option to say that
            there is no SOCKS proxy.

            I suspect the problem with javaws was fixed by:
            http://icedtea.classpath.org/hg/icedtea-web/rev/c4476a810053

            But I don't see what could be wrong with the plugin. Could follow the steps on
            http://icedtea.classpath.org/wiki/IcedTea-Web#Filing_bugs and attach the logs for the plugin?

            It's now 1.75 years later...

            AFAIR, with "plugin" I referred to the browser plugin that then uses javaws
            to start the app. When writing the title of the bug I didn't know which
            part of the setup is doing wrong, i. e. if it's the browser plugin that
            reads the proxy setup from the Firefox configuration, or if that is done
            by javaws, or if javaws does nonsense with a configuration read correctly
            by the browser plugin.

            >
            > I suspect the problem with javaws was fixed by:
            > http://icedtea.classpath.org/hg/icedtea-web/rev/c4476a810053
            >
            > But I don't see what could be wrong with the plugin. Could follow the steps
            > on http://icedtea.classpath.org/wiki/IcedTea-Web#Filing_bugs and attach the
            > logs for the plugin?

            Fedora 16 is long after EOL, and I've re-installed my computer with
            Linux Mint Debian Edition. This uses packages from Debian, the versions
            of the browser plugin and the javaws binary are:
            icedtea-6-plugin:amd64 1.3.2-1
            icedtea-netx:amd64 1.3.2-1

            I've so far not tried to test the error condition with LMDE, because I had
            to find my ways around this bug, and I use the workaround ever since. This
            means to use more than one browser, and have Firefox configured with no
            proxy, and working proxy settings in the other browsers.

            Should version 1.3.2 have the fix you mentioned? If so, then it would make
            sense to test again.

            If that particular changeset Omair linked is indeed the fix, then no, it would not be in 1.3.2. But
            could you check that 1.3.2 still exhibits this behaviour? Perhaps it was fixed by some other changeset
            since 1.1.4.

            The first bug is that passing simple number or Number object to method(int param) leads to 'Error
            calling method on NPObject', but passing String to the same method works fine.

            The second problem is broken arrays support. So, passing simple JavaScript array like [1, 2, 3] or new
            Array(1, 2, 3) to method(byte[] array) (byte type used for example, actually all other types I tried
            (String[], int[], Object[]) do not works correctly) leads to calling method with empty array
            (array.length=0).

            No such problems with Sun's plugin.

            Tested on Chromium 13 and Firefox 4 on Ubuntu 11.04 x86_64.

            Here's some tests which don't work with IcedTea plugin
            http://opensource.apple.com/source/WebCore/WebCore-955.66/manual-tests/liveconnect-applet-array-parameters.html

            Enclosed a patch, which ensures that the packed resources are deleted from the cache. They are no longer
            needed because only the unpacked resources are accessed.

            http://docs.oracle.com/javase/7/docs/jre/api/javaws/jnlp/javax/jnlp/ExtensionInstallerService.html

            IcedTea 1.8.9, released to fix CVE-2011-2513, fails to build on Ubuntu with the following errors:

            /build/buildd/openjdk-6b18-6b18-1.8.8/build/bootstrap/jdk1.6.0/bin/javac -g -encoding utf-8 \
            -d /build/buildd/openjdk-6b18-6b18-1.8.8/build/netx.build \
            -classpath /build/buildd/openjdk-6b18-6b18-1.8.8/build/lib/rt:/usr/lib/jvm/java-gcj/jre/lib/rt.jar \
            -sourcepath
            /build/buildd/openjdk-6b18-6b18-1.8.8/build/../netx:/build/buildd/openjdk-6b18-6b18-1.8.8/build/generated:openjdk-ecj/jdk/src/share/classes:openjdk-ecj/jdk/src/solaris/classes:openjdk-ecj/langtools/src/share/classes:openjdk-ecj/corba/src/share/classes
            \
            -bootclasspath \'\' \
            @netx-source-files.txt
            incorrect classpath: ''
            ----------
            1. ERROR in
            /build/buildd/openjdk-6b18-6b18-1.8.8/build/../netx/net/sourceforge/jnlp/runtime/CachedJarFileCallback.java
            (at line 84)
            public JarFile retrieve(URL url) throws IOException {
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            The method retrieve(URL) of type CachedJarFileCallback must override a superclass method
            ----------
            2. ERROR in
            /build/buildd/openjdk-6b18-6b18-1.8.8/build/../netx/net/sourceforge/jnlp/runtime/CachedJarFileCallback.java
            (at line 120)
            public JarFile run() throws IOException {
            ^^^^^^^^^^^^^^^^^^^^^^^^
            The method run() of type new PrivilegedExceptionAction<JarFile>(){} must override a superclass
            method

            This looks to my untrained eyes to be an issue caused by the semantic difference in the @override
            keyword between 1.5 and 1.6; icedtea 1.8.x builds with '-source 1.5' specified in a number of places,
            whereas 1.9.x and newer specify '-source 6' by default.

            Complete build failure log attached

            What ecj is being used here? As far as I can tell, everything will be compiled as 1.5 (javac.in)
            contains this and the classes referenced should contain those methods.

            You could try with the attached patch to remove the redundant @Override annotations. They don't have any
            value anyway and I don't know why they were added.

            ecj is 3.5.1-1 from Ubuntu 10.10 (aka maverick). We only build the icedtea 1.8.x series for ARM (armel);
            for all other architectures we support, we use 1.9.x or newer.

            Since there is no public API to handle Jar Indexes, the only options are to either keep the dependency
            or copy it over. The copy option may be considered for 2.0, but not before then.

            We have a problem with classloader, we have a main JNLP, and we use some JNLP as extension. These JNLP
            contains some jar used in application from main JNLP. We have some errors because classloader don't load
            correctly resources from jar declared in extended JNLP used in main application.

            On the other hand, if we put all jar in only one JNLP, all is ok.

            With javaws from oracle, we have no problem with use of some JNLP as extension to load some jar.

            Cordially

            We have run Eclipse debugger when we run application to find the problem, and we find that an exception
            is catch because there is a config file that is not loaded. This file is client-config.wsdd, it is
            located in axis.jar\org\apache\axis\client\

            Otherwise, if we activate log4j debug level, an exception is throw in another place because of a message
            cannot be read. This message is present in a ".properties" file.

            That what I was afraid. Thanx. Reproducer downloaded and in queue.

            There is 2 JNLP, one with log4j debug mode activated, maybe you need to change path of log4j properties
            file in JNLP and re-sign jar.

            Second JNLP doesn't load log4j properties file.


            There is 2 JNLP because exception is not the same if debug mode is activated or not.

            Application display a button that init Axis client, if init is OK, “OK” is displayed (This is the case
            for javaws Oracle). For Iced Tea, this is not the case, there is an exception that is not visible in
            console but visible in eclipse debug mode.

            adds a new dependency on sun.net.www.protocol.jar.URLJarFile

            In that they are not recognized as such, it then attempts to acquire permissions based on the system
            policies, which then fails and leads to an exception.
            I think if the jre directory contains blank characters, the problem also appears under linux.
            The problem arises from comparing a URL with a platform-specific string.

            Under linux e.g. made the following comparison that works.

            "/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunjce_provider.jar".startsWith("/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext");

            Under windows e.g. made the following comparison that does not work.

            "/C:/Program%20Files/Java/jre1.8.0_201/lib/ext/sunjce_provider.jar".startsWith("C:\Program
            Files\Java\jre1.8.0_201\lib\ext");

            Enclosed a patch that fixes the problem.