problems with Java 1.7.0_21 and the dev_appserver

538 views
Skip to first unread message

Gary Frederick

unread,
Apr 29, 2013, 6:37:36 AM4/29/13
to google-a...@googlegroups.com
Many of us are unable to get our apps to run with the dev_appserver when we update to Java 1.7.0_21. It works again if we go back to 1.7.0_17 or Java 6.

The error

java.io.IOException: Cannot find cached resource for URL: http://localhost:8888/ode2/webstartfile/v132-16-g0025b7e_d824h4eddfpc0kipeldr4iva1k9hgrc4x1ozk7q86g0hjtqzv82hheizrfaervtvr05omhmta51gkm9qasqckx8vr61zt1nzb2e52wp365oj0q69kjkdikxo0e8nc7b80takai1o3n/BlocksEditor.jar
    at com.sun.deploy.cache.Cache.getCachedResourceFilePath(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getCachedResourceFilePath(Unknown Source)
    at com.sun.javaws.security.JNLPSignedResourcesHelper.getSignedJNLPBits(Unknown Source)
    at com.sun.javaws.security.JNLPSignedResourcesHelper.getSignedJNLPFile(Unknown Source)
    at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedLaunchDescHelper(Unknown Source)
    at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedLaunchDesc(Unknown Source)
    at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedLaunchDesc(Unknown Source)
    at com.sun.javaws.Launcher.prepareResources(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(Unknown Source)

any ideas what to do to get it to work?

Gary

Mathias Kegelmann

unread,
May 23, 2013, 9:01:51 AM5/23/13
to google-a...@googlegroups.com
I'm not sure this helps, but here's what I observed:

- Looking at the stacktrace and com.sun.javaws.security.JNLPSignedResourcesHelper, com.sun.deploy.cache.ResourceProviderImpl.getCachedResourceFilePath and com.sun.deploy.cache.Cache.getCachedResourceFilePath I think that javaws is looking for the cached BlocksEditor.jar
- When I run the JRE 6 javaws I get an entry in the cache containing the JAR file
- Using the JRE 7 javaws there is no such file
  - Adding <offline-allowed/> to the JNLP file has no effect. (Just tried to be sure.).

The only other detail I noticed is that "jarsigner -verify" and also the ant task signing the JAR report the following warning: "This jar contains entries whose signer certificate will expire within six months.". 

I wonder if that might trigger the behavior.

- Mathias

Mathias Kegelmann

unread,
May 25, 2013, 6:42:13 AM5/25/13
to google-a...@googlegroups.com
I ran some more experiments to narrow down the problem:

- I made a tiny test webstart project with a self signed JAR and that works fine with 1.7u21.
- If I start the program from saved files - JNLP file on the local disk, JAR on the disk and the JNLP adapted so it uses the local JAR - everything also works fine.
- JNLP on disk and JAR from the server does NOT work.
- JNLP on disk and JAR served by another server (I used "python -m SimpleHTTPServer) it DOES work.

So, as far as I can tell, webstart checks for some meta information In the HTTP response to decide if it saves the file.

It also looks more and more like a bug in 1.7u21: The error message is not helpful, since the problem seems to occur earlier when javaws decides not to store the JAR in the cache.

- Mathias

Mathias Kegelmann

unread,
May 25, 2013, 6:49:23 AM5/25/13
to google-a...@googlegroups.com
Just looked at the headers the app sends:

  HTTP/1.1 200 OK
  X-TraceUrl: /appstats/details?time=1369478620521&type=json
  Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  Pragma: no-cache
  Expires: Fri, 01 Jan 1990 00:00:00 GMT
  content-disposition: attachment; filename="BlocksEditor.jar"
  Content-Type: text/plain; charset=utf-8
  Content-Length: 1475708
  Server: Development/1.0
  Date: Sat, 25 May 2013 10:43:40 GMT

and the content type is clearly wrong. So maybe it's a problem with AppInventor after all.

- Mathias

Gary Frederick

unread,
May 25, 2013, 7:54:20 AM5/25/13
to google-a...@googlegroups.com
It works if you use Java 1.7.0_17 (and Java 6). Is there a difference in the headers with the older version?

Gary

Mathias Kegelmann

unread,
May 25, 2013, 8:43:39 AM5/25/13
to google-a...@googlegroups.com
On Saturday, 25 May 2013 13:54:20 UTC+2, Gary Frederick wrote:
It works if you use Java 1.7.0_17 (and Java 6). Is there a difference in the headers with the older version?

Gary

I don't think the headers changed, I think that javaws interprets the HTTP headers in a stricter way. I narrowed it down to the header:

 Cache-Control: no-cache, no-store, max-age=0, must-revalidate

If this line is not present, then everything works (I didn't investigate further which of the four attributes is the problem). So it seems that with this header the JAR file is not stored in the webstart cache and then later when javaws validates it it cannot find the cache in com.sun.deploy.cache.Cache.getCachedResourceFilePath with results in the java.io.IOException.

I'll post the patch in the AppInventor group in a minute.

- Mathias

Gary Frederick

unread,
May 25, 2013, 12:25:15 PM5/25/13
to google-a...@googlegroups.com
!!!

Thanks for the post and the research

Gary
Reply all
Reply to author
Forward
0 new messages