Skip to main content

JWS file caching problem - desktop shortcut fails to update/launch

3 replies [Last post]
pes17
Offline
Joined: 2007-11-05

Hi.

I have encountered weird caching problems when using JWS and dynamic JNLP + JNLPDownloadServlet. JNLP file is generated on the server by servlet. Servlet mapping is defined as follows:

JNLPServlet = "/client/client.jnlp"
JNLPDownloadServlet = "/client/*"

where all JAR files are obviously stored in "client" dir.

We need the client to always ask for new version of JNLP on startup because it needs updated runtime parameters. I can see in the log that clients are being served with the file.

Based on different hints found on the net the headers of JNLP file are set as follows:

<br />
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)<br />
                throws ServletException, IOException {<br />
        try {<br />
            StringBuffer url = req.getRequestURL();<br />
            String doc = req.getRequestURI().substring(req.getRequestURI().lastIndexOf("/"));</p>
<p>            resp.setHeader("Expires", "0");<br />
            resp.setCharacterEncoding("UTF-8");</p>
<p>            String attachment = "inline; filename=\"" + doc.substring(1) + "\"";<br />
            resp.setContentType("application/x-java-jnlp-file");<br />
            resp.setHeader("Cache-Control", "must-revalidate");<br />
            resp.setHeader("Content-disposition", attachment);<br />
            Calendar timeStamp = Calendar.getInstance();<br />
            resp.addDateHeader("Date", timeStamp.getTimeInMillis());<br />
            resp.addDateHeader("Last-Modified", timeStamp.getTimeInMillis());<br />

To minimize download sizes we have also version.xml files with all JARs listed explicitly and this works as supposed to.

This always works as expected when we launch the application using URL, e.g. http://server/client/client.jnlp. The client is served with updated JNLP and if some JARs were updated, only those are sent to client and client is launched happily.

However when it is launched using desktop icon it totally misbehaves. Any attempt to launch ends up with error message:

Could not load file/URL specified: C:\Users\user\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\32\525ca1a0-6d4dee15

Indeed, the file is not there. Only the same file with ".idx" extension. Server log says that JNLP file was sent, the desktop icon disappears and reappears (=> was updated from the server) and than above mentioned message is present in "Unable to launch application" error dialog.

Any hints please? There must be some major misunderstanding in the way I am trying to use JWS :(

Also, not so unrelated, I have tried to put explicit timestamp to JNLP file as described here http://java.sun.com/j2se/1.4.2/docs/guide/jws/downloadservletguide.html#..., by placing "TS: " line on top. This always resulted with inability to launch and error claiming that mandatory element is not present in JNLP file. The only difference between this and my semi-functional JNLP is only that TS line on top.

Environment: JRE6u12, Vista, UAC active (i.e. user is not admin)

Thank you,
pes

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pes17
Offline
Joined: 2007-11-05

Thanks for reply. As for issue with MSIE6 I don't think so as we can reproduce that on Vista (==>no IE6).

Oh well, seems like we must wait till JDK6u14 ....

vossp2
Offline
Joined: 2004-07-02

We have experienced similar problems with Java Web Start.

First, Java 1.6.0_12 and 1.6.0_13 we cannot get the shortcut to work under any circumstances. We have all our clients use Java 1.6.0_11 or earlier. Install the Java VM update 11, and I bet your shortcut will begin to work.

One forum post claimed this is to be fixed in the forthcoming release 14, but the early release has the same issue.

That being said, there's another issue, which if the user later re-launches the JNLP from the website, the desktop shortcut may break again. I think *that* issue is specific to Java 6 update 11, and was okay in update 6, but we're still testing that.

vossp2
Offline
Joined: 2004-07-02

One more note, we suspect the problem with shortcuts breaking are related to Internet Explorer 6. It does not seem to appear on machines with IE7 or on Macs.

Another forum post claimed this is to be fixed in the upcoming release 14, but we could recreate the problem with the release 14 preview b05.