v1.5 app fails with "Cannot find cached resource" in v1.6

After upgrading to v1.6 my application cannot start (after importing the jar files manually into the cache).

Unable to launch application

Error: Cannot find cached resource for URL:http:/server/jar1.jar

The application is supposed to run online as well as offline.

When running online I want the jws cache to be updated with the server version of the application.

Since it must also run offline, I import the jar files to the jws cache during installation of the application.

Using JRE 1.5 everything works fine. I import the jar files using:

javaws -import -silent -codebase "file:/c:\my-java-code" "file:/c:\my-java-code\my-app.jnlp"

and I can start the application by the command line:

javaws C:\my-java-code\my-app.jnlp

If there is no connection to the server, the application starts in offline mode.

If the server is available, the new server-side version of my-app is downloaded and started.

Unfortunately this does not work with jre/jws 1.6

If there is no connection to the server, the application from cache starts up fine.

If the server is available, jws downloads the newer version but fails with:

Unable to launch application

Error: Cannot find cached resource for URL:http:/server/jar1.jar

The only workaround I can find is by creating a copy of the jnlp file where I add 'version="+"' to each <jar> tag.

If I import this one:

javaws -import -silent -codebase "file:/c:\my-java-code" "file:/c:\my-java-code\my-app-INSTALL.jnlp"

I can start the application using the original jnlp file:

javaws C:\my-java-code\my-app.jnlp

my-app-INSTALL.jnlp still references my-app.jnlp in the <jnlp> tag.

Unfortunately this does not work with jre/jws 1.5.

I am also uncomfortable using this approach since I don't know why it works :-)

Any ideas of what is going on here and a safe solution that works for both 1.5 and 1.6 (at least for 1.6 and upcoming releases)?

my-app.jnpl (superfluous info removed)

<?xml version="1.0" encoding="UTF-8"?>

<jnlp spec="1.5" codebase="http://server" href="my-app.jnlp">

<information>

<offline-allowed/>

</information>

<security>

<all-permissions/>

</security>

<resources>

<j2se max-heap-size="512m" version="1.5+"/>

<jar href="jar1.jar" main="true"/>

<jar href="jar2.jar"/>

</resources>

<application-desc main-class="app.MainEntryPoint">

<argument>arg1</argument>

<argument>arg2</argument>

</application-desc>

</jnlp>

my-app-INSTALL.jnpl (superfluous info removed)

<?xml version="1.0" encoding="UTF-8"?>

<jnlp spec="1.5" codebase="http://server" href="my-app.jnlp">

<information>

<offline-allowed/>

</information>

<security>

<all-permissions/>

</security>

<resources>

<j2se max-heap-size="512m" version="1.5+"/>

<jar href="jar1.jar" main="true" version="+"/>

<jar href="jar2.jar" version="+"/>

</resources>

<application-desc main-class="app.MainEntryPoint">

<argument>arg1</argument>

<argument>arg2</argument>

</application-desc>

</jnlp>

[3520 byte] By [henrikaxa] at [2007-11-27 2:52:00]
# 1
Sorry - I made a mistake in the previous post.For the workaround to work, I must modify my original v1.5 jnlp file and add:version="+"to every <jar> tag.The my-app-INSTALL.jnlp is just a copy of the original v1.5 jnlp
henrikaxa at 2007-7-12 3:25:41 > top of Java-index,Desktop,Deploying...
# 2
Are you sure you want the JNLP codebase to be http://server ?
riema at 2007-7-12 3:25:41 > top of Java-index,Desktop,Deploying...
# 3

The code is located on the server like http://server/jar1.jar.

"server" is just a name I used here. It resolves to an IP address in the 'real' jnlp file.

I guess that makes the codebase http://server valid?

It works fine with v1.5.

When I import the codebase to the jws cache, the javaws command line points to a local folder containing a version of the same files as located on the server.

At the moment I'm using the workaround (as described on the first two posts) if the installer detects Java version 1.6.

My concern is just that this wont work with the next release 6u2 as it does not work with version 1.5.

/Henrik

henrikaxa at 2007-7-12 3:25:41 > top of Java-index,Desktop,Deploying...
# 4

There is a discrepancy in class file types in 1.5 and 1.6 java.

Follow this link.

Any one have any idea why the backward compatibility has been NOT Taken care?

http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/pack200.html#testing

Exception in javaws is as below.

java.io.IOException: Corrupted pack file: magic/ver = CAFED00D/160.1 should be CAFED00D/150.7

at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method)

at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)

at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)

at com.sun.java.util.jar.pack.UnpackerImpl.unpack(Unknown Source)

at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)

at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)

at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)

at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)

at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)

at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)

at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)

at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)

at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)

at com.sun.javaws.Launcher.downloadResources(Unknown Source)

at com.sun.javaws.Launcher.prepareLaunchFile(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$1.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

Need help in getting a work around for this.

bharath-javaa at 2007-7-12 3:25:41 > top of Java-index,Desktop,Deploying...
# 5
Have you tried using forward slashes for the codebase?
riema at 2007-7-12 3:25:41 > top of Java-index,Desktop,Deploying...