0

I have been attempting to use JWrapper for deployment of a Java application that I'm developing, but I have been unable to succeed in getting the "online" Windows installation of my application to work in coordination with either Google Drive's webhosting facilities (my first choice for file server) or DropBox (my second choice for file server). A perusal of the log generated when I execute [myApp]-windows64-online.exe suggests that the jWrapper install mechanisms are failing to access the remote installation files (both in the case of my Google Drive implementation and my DropBox implementation).

(BTW, the "offline" Windows installation for my application works perfectly.)

For purposes of more easily addressing this problem with JWrapper support folks (and whoever else might reply on this thread) I've successfully emulated the problem with the JWrapper sample application.

To enable online installation with the sample application, I added one extra element to the jWrapper sample application's build parameters:

<UpdateURL>https://googledrive.com/host/0B0skoeyva4KiU01RbmYxS3JLYmc/</UpdateURL>

This is the public URL for the folder that I have created in Google Drive to hold the contents of the "build" folder that JWrapper produces for the sample application. I then ran the JWrapper build process for the sample application using the latest version of JWrapper (jwrapper-00033253833.jar), and copied the contents of the resultant "build" folder to the above-referenced Google Drive folder.

I then opened the provided sample html for downloading the "online" version of the sample application installation: 

https://googledrive.com/host/0B0skoeyva4KiU01RbmYxS3JLYmc/SampleAppEmbedExample.html

On the webpage above I clicked on the "Download SampleApp" button, which resulted in the download of SampleApp-windows64-online.exe, which I executed. I then clicked on "Run" in the resultant security warning (no certificate with the sample application), and the JWrapper splash window appeared for a couple of seconds and disappeared. The Windows Task Manager showed that all JWrapper processes had terminated.

The resultant installation log file that was generated is here: https://googledrive.com/host/0B0skoeyva4KiU01RbmYxS3JLYmc/Wrapper-2015-01-13-14-49-33-805.log

To summarize the log contents, it seems that a number of remote download attempts all fail, and the entire install process terminates with the following message:

[JREDownload] Failed to download JRE version file

I repeated the entire build and install sequence using DropBox as a file server, with similar results. The installation log file for that is here: https://dl.dropboxusercontent.com/u/2023253/jwSample/Wrapper-2015-01-13-15-24-13-778.log

These results perfectly emulate what I am experiencing with my much-larger Java application when attempting a similar "online" installation with JWrapper-generated components.

Thanks for any assistance that anyone can provide with this issue.

BTW, the instructions I followed for using Google Drive for web hosting are here:

  http://googleappsdeveloper.blogspot.com/2012/11/announcing-google-drive-site-publishing.html

EDIT 2015-01-15

I noticed that the output log generated by the JWrapper online installation process seemed to show a number of failures to retrieve file lengths from the remote server ("Required file size is unknown!") prior to outputting its final message of "Failed to download JRE version file" and terminating. My further testing confirms that a Google Drive HTTP connection always returns 0 when the getContentLength method is invoked to ascertain a file's length. However, the file can still be downloaded without any problems in my testing.

I do not have access to the JWrapper source code, but might it be that the JWrapper installer is misinterpreting a file length of 0 as being synonymous with "file inaccessible"?

Daniel Vimont
  • 31
  • 6

1 Answers1

0

Google Drive is apparently using 302 redirects on the files when they are accessed. Here's a sample response from the URL for your HTML file:

HTTP/1.1 302 Moved Temporarily
Location: /start
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Date: Sat, 17 Jan 2015 11:14:13 GMT
Expires: Sat, 17 Jan 2015 11:14:13 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alternate-Protocol: 443:quic,p=0.02
Transfer-Encoding: chunked

Given the redirect URL it would seem Google is using this query to prepare the transfer and then expects the file to be delivered by requesting /start in the same HTTP/1.1 session.

I believe JWrapper doesn't currently support redirects for the file downloads which is the likely cause of this issue but I'll make a note for us to look into it in the future. In the time being though you would need to use a service which delivered the files without redirects.

AntonyM
  • 1,602
  • 12
  • 12
  • Yes, I was aware that Google Drive always redirects HTTP calls, but given the ubiquity of redirects in HTTP traffic, it didn't occur to me to mention it. It's surprising that JWrapper's download logic does not handle HTTP redirects. I would be happy to beta test a fix for this, when the development team gets around to it! (I would hope it's not too complicated a fix: If the response code indicates a redirect, just get the new URL from the connection's getHeaderField("Location") method and reissue the call.) – Daniel Vimont Jan 19 '15 at 11:31
  • The way JWrapper deployment to a server works it typically wouldn't involve redirects since the idea is to just dump the built files onto a web server and then let JWrapper manage the update process from there with no server side logic at all. Google drive isn't a method of hosting that had occurred to us but would be very convenient. We want to support it though so we will look at it in the future. The change probably won't be complex but we do need to make the change for all platforms and test it thoroughly, we should be able to get this into some changes coming in the next few months. – AntonyM Jan 19 '15 at 13:51
  • Thanks very much! I'd appreciate any attention you can give this issue. And I really appreciate ALL that you're doing with JWrapper. In my book, it's the only way to make distribution of stand-alone Java applications viable (given all the drawbacks that I've encountered when trying to use JNLP -- ugh!). – Daniel Vimont Jan 20 '15 at 23:25