FailedDownloadException on Mojave

Recently I have learned of an issue affecting a jogl-based Webstart application that I authored (and tested) nearly a year ago. Now every attempt to run the application reports a FailedDownLoadException when trying to load the resource " http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp". The failure stems from an illegal URL redirect (see below).

Launch File tab:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://people.uncw.edu/moyerc/QMTools/webstart" href="QMTools.jnlp">
  <application-desc main-class="edu.uncwphys.qmtoolsexe.QMToolsMain"/>
  <information>
    <title>QMTools Applet Editor</title>
    <vendor>Curt A. Moyer</vendor>
    <homepage href="http://people.uncw.edu/moyerc/QMTools"/>
    <icon href="qmtools_icon.gif"/>
    <description>An open source editor for QMTools applets</description>
    <offline-allowed/>
  </information>
  <update check="background" policy="always"/>

  <security>
      <all-permissions/>
  </security>

  <resources>
    <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/>
    <property name="sun.java2d.noddraw" value="true"/>
    <jar href="qmtools.jar" main="true"/>
    <extension name="jogl-all-awt" href="http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp"/>
  </resources>
</jnlp>
Exception tab:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp
        at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
        at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getJreResource(Unknown Source)
        at com.sun.javaws.LaunchDownload._downloadExtensionsHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
        at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
        at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.launch(Unknown Source)
        at com.sun.javaws.Main.launchApp(Unknown Source)
        at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
        at com.sun.javaws.Main.access$000(Unknown Source)
        at com.sun.javaws.Main$1.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
Wrapped Exception tab:
java.lang.SecurityException: illegal URL redirect
        at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
        at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
        at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
        at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
        at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
        at com.sun.deploy.cache.ResourceProviderImpl.getJreResource(Unknown Source)
        at com.sun.javaws.LaunchDownload._downloadExtensionsHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
        at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
        at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.launch(Unknown Source)
        at com.sun.javaws.Main.launchApp(Unknown Source)
        at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
        at com.sun.javaws.Main.access$000(Unknown Source)
        at com.sun.javaws.Main$1.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

I have confirmed this on an iMac as well as a MacBook Pro, both running under Mojave 10.14.6. The former uses the latest Java version (JRE 8 Update 241) while the latter uses the older JRE 8 Update 221, but the behavior is the identical on both. Even more troubling, I see the same issue when trying to run the Gears Webstart application on jogamp.org, as well as the (simpler?) versioning application on that site. Thus, the problem does not appear to lie with my application. For reference, I can confirm that everything worked as intended as recently as last October. What is the problem and, more importantly, how can it be fixed?

You would need to use the specific JogAmp version URL,
as 'jogamp-current' might have changed.

As long we still host the older version, it should be 'as it was'.

~Sven

On 3/6/20 5:20 PM, camac [via jogamp] wrote:
> Recently I have learned of an issue affecting a jogl-based Webstart
> application that I authored (and tested) nearly a year ago. Now every attempt
> to run the application reports a FailedDownLoadException when trying to load
> the resource " http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp".
> The failure stems from an illegal URL redirect (see below).
>

snip

>
>   <resources>
>     <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/>
>     <property name="sun.java2d.noddraw" value="true"/>
>     <jar href="qmtools.jar" main="true"/>
>     <extension name="jogl-all-awt"
> href="http://jogamp.org/deployment/jogamp-current/jogl-all-awt.jnlp"/>
>   </resources>
> </jnlp>

Sven,
Thanks for your quick response, but I'm afraid it didn't help. It seems I get this FailedDownloadException whenever a Webstart application tries to access a resource from the jogamp site. For example, when I launch the versioning Webstart application on the main Jogl page, I get the following message:



The accompanying wrapped exception references a URL redirect, as per my original post. A similar thing occurs when I attempt to launch the Gears webstart application on the Jogl demos page. I've never experienced such problems before, so I'm at a loss to know how to proceed. Please advise.

Can you show the wrapped exception?

Sure; here it is:



Again, I welcome any suggestions you might have.

The only redirect that happens is the conversion from http to https by jogamp.org webserver
the jogamp webserver redirects all http requests to https
this upset the javaws tool, that are then unable to locate the jnlp codebase using http (it gets redirected)

what will not work:
all jnlp that uses jars from jogamp.org using http:// in the jnlp will run into this exception using oracle's javawebstart implementation.

note that all current jnlp demo files hosted by jogamp currently use http:// in the jnlp

solution:
all jnlp that uses jars from jogamp.org must use https:// in the jnlp

Xerxes,
Thank you for the insight but what exactly can I do -- if anything -- to have my application launch without running into this problem? (I tried simply replacing http: with https: in the jogl resource line of my application's jnlp file, but that didn't work.)

Did the exception/error message chang at all? Does it still say "cannot load resource <http:// version of url>?"

Do you really want to go on using Webstart whereas it's deprecated and it was removed from Java?

I don't know what chang means but, yes, the error message is unchanged (as if I hadn't made any changes to the jnlp file). As for abandoning Webstart, that's going to involve a lot more time and effort than I prepared to give at this time. Indeed, I was not aware that Webstart was deprecated.

Sorry, typo. Meant 'change'

If the error is still referencing the http version of the URL, that suggests that perhaps you were not _using_ the updated jnlp, of perhaps that there are multiple references requesting this resource, some which were not changed?

(Don't know anything about web start... Just reasoning back from the error message...)

as discussed, I will attempt to 'open the door' for this
non-https JNLP download, i.e. not redirecting these URLs.

But I won't go any further for now.

For 2.4.0 release, I would need to know if there are
any JNLP interested parties or not, worth the effort.
However, we won't sign the JARs anymore
and the old JARs's signature has expired.

Your mileage may vary .. (YMMV).

Will report here when I did the 'redirection hole'.

~Sven

On 3/9/20 1:30 PM, Xerxes Rånby [via jogamp] wrote:

camac wrote

Xerxes,
Thank you for the insight but what exactly can I do -- if anything -- to have my application launch without running into this problem?

The thing you can do to be 100% sure that webstart work is by placing all gluegen and jogl jars on your own server.  Update your jnlp to only use jars from your own webserver. you may need to sign all jars on your own webserver with your own certificate.

This solution to host all jars and jnlp on your own server will work for the entire Oracle java 8 lifetime.
The solution will also work when using alternative webstart implementations such as:
openwebstart https://openwebstart.com/
icedtea-web https://icedtea.classpath.org/wiki/IcedTea-Web

Interesting that you should mention OpenWebStart, which I found after learning (in an earlier post) that Webstart was officially deprecated by Oracle. I can now report that OpenWebStart handles the redirection on the Jogamp site without incident, at least using the hardware configuration available to me (Mac platform running Mojave 10.14.6). Initially, you must respond to numerous prompts, but all can be avoided in future invocations by checking the appropriate boxes. The only real downside I see so far is that loading tends to be unusually slow -- perhaps this can be improved in a future release.

For me and for now, this appears to be the best solution, inasmuch as it is immediately available and requires no changes to my application.

I'd like to add that my journey starting from Java Applets to Webstart applications and now Oracle's complete abandonment of this platform has been very frustrating. I continue to believe the interactivity offered by Java Applets is unmatched from an educational standpoint, and still has its place if only the necessary security issues could be overcome. Their demise is regrettable...

Finally, my thanks to everyone who contributed to this post, their wisdom having saved me countless hours of time and effort in arriving at a remedy that should be satisfactory, at least in the short run.

It's a dead end. Webstart and applets are too difficult to maintain. I used Webstart for a very long time, I worked around numerous bugs and limitations. Nowadays, only a very few end users still have a JRE installed on their computers. Packaging a software for OS X is challenging, the stupid Gatekeeper gets in your way. I advise you to look at the alternatives, JPackage for example. I use my own packager because it's more cross-platform than Oracle's solution, I can create native packages for Windows and OS X under GNU Linux :)