Skip to main content

Does javaws import option work with version protocol?

12 replies [Last post]
toddm
Offline
Joined: 2005-01-26
Points: 0

Has anyone ever got webstart to import into the cache from the local file system? and/or run offline without access to the webserver? using version info in jnlp and file names?

If I use command line of
javaws -import -codebase "file://C\:/Program Files/JettyWebServer/jetty-5.1.1/webapps/jnlp/app/impLevelVerswebpad" "C:\Program Files\JettyWebServer\jetty-5.1.1\webapps\jnlp\app\impLevelVerswebpad\webpad.jnlp"

and the jnlp file contents are:

WebPad Levels Vers No 2nd JNLP
Sun Microsystems, Inc.

I get this error:
An error occurred while importing the application.

Title: WebPad Levels Vers No 2nd JNLP
Vendor: Sun Microsystems, Inc.
Category: Download Error

Unable to load resource: (http://localhost:8080/jnlp/app/impLevelVersNo2ndJNLPwebpad/webpad/webpad..., 1.0)

With this exception:
JNLPException[category: Download Error : Exception: java.net.UnknownHostException: C : LaunchDesc: null ]
at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.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.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Which is understandable as I have the localhost web server turned off. What I don't understand is why javaws is trying to connect to the webserver, isn't the import codebase command supposed to force it to read files from the local file system?

My folder structure is:
..app\impLevelVersNo2ndJNLPwebpad\webpad.jnlp
\holiday__V1.0.jar
\webpad\webpad__V1.0.jar
\jlfgr\jlfgr__V1.0.jar

If I change the JNLP file to use $$codebase it get:
An error occurred while importing the application.

Category: Launch File Error

The field codebase has an invalid value: $$codebase

Which is expected as the jnlp hasn't been processed by the jnlp servlet.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lilianne_blaze
Offline
Joined: 2006-05-05
Points: 0

Well, yes, but it would more or less work, wouldn't it? I'm not saying it's enough, but it's a step up from not-working-at-all? :\

Also, what about the following scenario:

The app needs 3 jars - code.jar (reasonably small), graphics.jar (very big), graphics2.jar (very small, increasing in later versions). 1st and 3rd are versioned on the server, 2nd is not versioned and has modified-date set in the past (before the cd version was prepared and distributed), the idea is that it's not changing at all, and the 3rd one extends/overwrites it's entries as needed.

In this scenario web start would download 1st and 3rd, but not 2nd which is the biggest, correct?

mthornton
Offline
Joined: 2003-06-10
Points: 0

Versioned jars have two advantages. First they permit the use of jardiff downloads to obtain just the changes and secondly when starting the application webstart doesn't check the timestamp of the jar on the server --- if it already has the version specified in the JNLP file, no further check is required.

In our use of WebStart, we don't have any large non changing jars. Including the updates in another jar file and relying on classpath order to load the updates instead of the original is a trick I would prefer not to use (and in any case doesn't work when the app searches for all instances of a resource).

If you do have large static jar, then you might as well use the real timestamp for it.

lilianne_blaze
Offline
Joined: 2006-05-05
Points: 0

> Including the updates in another jar file and relying on classpath order to load the updates instead of the original is a trick I would prefer not to use (and in any case doesn't work when the app searches for all instances of a resource).

I'm aware of this. What I intend to use is more like: app needs "data/graphics/title.png", so it tries to load "patch1/data/graphics/title.png" (which would be in the small versioned jar or not present at all), failing that it tries to load "box/data/graphics/title.png" (which would always be in the large unversioned jar). So the order of jars doesn't matter.

scytacki
Offline
Joined: 2004-09-29
Points: 0

You can make it work, but you need to be running a local webserver. We did this with a stripped down version of jetty. So this way we can distribute a installer for the application on a usb stick or cd. So the installer works like this:
- start up local jetty
- run javaws -import

This page describes how to set it up:
http://confluence.concord.org/display/CCTR/Local+Webstart+Install+of+Ver...
If you go down to the section:
"initial design work"
you can see the initial scripts used to set it up and run it. The top section describes how we've packaged this into a set of scripts that make it easy to update the jars, and then install them.
These scripts use a jar we created called jnlp2shell that can take a jnlp file and download the jars and save them in the format expected by jnlp-servlet. You can see a project page for jnlp2shell here: http://source.concord.org/maven2/site/maven2-svn/deploy/jnlp2shell/
You can get to the javadocs and source repository from that project page.

onlyjava
Offline
Joined: 2003-10-17
Points: 0

This error happens because the request for the versioned jar is not directed to the jnlpdownloadservlet.
If you modify your web.xml like so, this error will go away.
Here the idea is that all requests to your app directory should be routed thru the jnlpdownloadservlet, not just *.jnlp

here's a web.xml that works for me

Cheers,

Kris



JnlpDownloadServlet
jnlp.sample.servlet.JnlpDownloadServlet

logLevel DEBUG

logPath /jnlpdownloadservlet.log



JnlpDownloadServlet

/*

mthornton
Offline
Joined: 2003-06-10
Points: 0

Sorry 'onlyjava' but you have missed the point. This thread is about the use of the -import option on javaws that was added in JDK5. This is supposed to allow the 'preloading' of the webstart cache from resources on a local disk (usually a CDROM). Unfortunately it does not work with versioned resources; this has now been confirmed by Sun engineers.

ea945
Offline
Joined: 2008-05-21
Points: 0

I know this is a pretty old thread and just wondering is this issue fixed for JRE 1.6? I am trying to do something similar using JRE 1.6:

javaws -import -system -codebase file:. client.jnlp

with the jnlp file:




Test Client









which give me this stack track in the "Exception" tab:

com.sun.deploy.net.FailedDownloadException: Unable to load resource: (file:./lit/clientAps.jar?version-id=123&current-version-id=123, 123)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(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)

and the stack trace in the "Wrapped Exception" tab:

java.io.FileNotFoundException: .\lit\clientAps.jar (???????????)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(Unknown Source)
at java.io.FileInputStream.(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequest(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.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)

the names of the jars are:
clientAps__V123.jar
bc__V123.jar

Can anyone advise me on this problem?

lilianne_blaze
Offline
Joined: 2006-05-05
Points: 0

Maybe it would help to remove version="xx" attributes from jnlp file intended for import, while retaining them in the online jnlp file?

mthornton
Offline
Joined: 2003-06-10
Points: 0

That won't help as as soon as it saw the online version of the JNLP file it would consider all the resources as different and download the whole lot. You have to populate the cache [b]with[/b] the version information if you are to avoid a subsequent download.

mbien
Offline
Joined: 2007-04-29
Points: 0

is there a bug report tracking this issue?

mthornton
Offline
Joined: 2003-06-10
Points: 0

None that I know of.

mthornton
Offline
Joined: 2003-06-10
Points: 0

The correct file url should be of the form file:///c:/etc
Unfortunately when you get it correct as in this example:

C:\development\webstart>javaws -codebase file:///c:/development/webstart/webpad
-import webpad\webpad.jnlp

You then get a different exception:

NLPException[category: Download Error : Exception: java.io.FileNotFoundException: c:\development\webstart\webpad\webpad.jar?version-id=1.0 (The filename, directory name, or volume label syntax is incorrect)

This time webstart is adding the version query to the filename. :-((