Skip to main content

Webstart fails with FileNotFoundException on ___system_s1as.jnlp

5 replies [Last post]
ianblav
Offline
Joined: 2012-10-24

G'day

I'm trying to get my first application client to work under web start. I'm getting the failure below on the client side - java.io.FileNotFoundException: http://localhost:8080/___JWSappclient/___system/___dyn/___system_s1as.jnlp.

I've tried one suggestion that I saw that was to undeploy the application, clear out the java-web-start directory in the Glassfish directory for the domain, redeploy the application, and try again. (I was expecting this to force re-population of the directory but it is as empty now as it was when I emptied it).

Given that the missing file is a JNLP file I'm thinking that what can't be found is the JNLP file sent by the server. I know this downloaded correctly since I can see it my browser downloads window. Whether it was put where it needs to go is another question.

Any suggestions before I raise a bug ?

java.io.FileNotFoundException: http://localhost:8080/___JWSappclient/___system/___dyn/___system_s1as.jnlp
at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1485)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
at com.sun.deploy.net.BasicHttpRequest.doRequest(BasicHttpRequest.java:230)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(BasicHttpRequest.java:67)
at com.sun.deploy.net.DownloadEngine.isUpdateAvailable(DownloadEngine.java:977)
at com.sun.deploy.net.DownloadEngine.isUpdateAvailable(DownloadEngine.java:882)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1619)
at com.sun.deploy.net.DownloadEngine.getCachedFile(DownloadEngine.java:661)
at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(LaunchDownload.java:711)
at com.sun.javaws.LaunchDownload.downloadExtensions(LaunchDownload.java:654)
at com.sun.javaws.Launcher.prepareLaunchFile(Launcher.java:707)
at com.sun.javaws.Launcher.prepareAllResources(Launcher.java:597)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:336)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:208)
at com.sun.javaws.Launcher.launch(Launcher.java:125)
at com.sun.javaws.Main.launchApp(Main.java:451)
at com.sun.javaws.Main.continueInSecureThread(Main.java:283)
at com.sun.javaws.Main$1.run(Main.java:116)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.io.FileNotFoundException: http://localhost:8080/___JWSappclient/___system/___dyn/___system_s1as.jnlp
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1434)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at com.sun.deploy.net.BasicHttpRequest.doRequest(BasicHttpRequest.java:191)
... 16 more

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tjquinn
Offline
Joined: 2005-03-30

Please tell us what operating system type and version you are running, what version of Java you have on the client and server sides, and what release of GlassFish you are using.

Also, are you using the same system for the client and the server in this test?

The JNLP document URL in the error is one that GlassFish generates, and it is the same for any application.

Are there any exceptions in the server.log file for the server logged at the time you try to launch the client?

- Tim

ianblav
Offline
Joined: 2012-10-24

G'day

I'm on Mac OS X 10.6.8 (can't go higher), Java 1.6.0_33 (server and client side), and Glassfish 3.1.2. Glassfish is running under NetBeans control.

Glassfish 3.1.2.2 doesn't install and either it or Java 1.6.0_39 no longer has the bouncycastle provider installed which is a problem I haven't overcome yet. Don't want to go there.

The JWS call fails both on the combined NetBeans / Glassfish host and another Mac on the local network running the same browser and Java version.

There are no exceptions thrown in the Glassfish log during the attempted launch of the client.

Unlike I reported earlier there is now a file called '___system_s1as.jnlp' present in the domain java-web-start directory. So presumably:

'http://localhost:8080/___JWSappclient/___system/___dyn/'

in the call isn't resolving in Glassfish to the domain java web start directory.

A permissions problem or similar is unlikely since someone, presumably Glassfish, wrote the jnlp file there in the first place.

I've tried the failing URL by hand now that there is a file in the domain JWS directory. As expected no resource is returned so the FileNotFound diagnostic is accurate.

I've done nothing that I am aware of to upset successful resolution of the path in the URL - I'm working in the standard domain1. There aren't even any spaces in the names of any of the directories in the path to the domain JWS directory. And again Glassfish was able to follow the path to write the file.

One thing I have tried is to properly deploy the client for JWS. As you are probably aware application clients are automatically JSW enabled in Glassfish. However they don't show as such in the admin server. They can be made to show as such by (in the admin server): undeploying the NetBeans deployed client; deploying the client (which doesn't offer JWS enablement); and redeploying the client and selecting JWS enablement (which is now offered). The client then shows as JWS enabled. If makes no difference whether I do this or not - the same FileNotFound exception is still thrown.

-- Ian

tjquinn
Offline
Joined: 2005-03-30

Hello, Ian.

You said that you have the same version of Java on the server and client side. Does this mean you are using separate systems for the client and server?

If so, then the problem might come from using "localhost" in the host name when the client is being launched. If the GlassFish server is not running on localhost then Java Web Start will be unable to retrieve the required files (including the JNLP document) from localhost:8080.

My suggestion: If you have successfully deployed the app then the server.log will contain a message that tells what the path (that is, the URL excluding the host and port) for launching the app client. If the GlassFish server is running on server X then from any system with Java (and therefore Java Web Start installed) you should be able to launch the client using this command:

javaws "http://X:8080/path-to-client"

where 'path-to-client' is the path from the server.log file. (I am assuming here that you are using the default HTTP port of 8080. If you have customized GlassFish to use another port then specify that port in the javaws URL.) If you don't see such a message in the server.log file then the deployment was done in a way that does not enable Java Web Start support for the client(s) in that app.

Launching this way (using the javaws command) simplifies things by taking some moving parts out of the picture (NetBeans, the admin console).

Please try that and let us know what you find.

- Tim

P.S. Yes, I'm aware that GlassFish provides automatic Java Web Start support for app clients. I'm the engineer who built the Java Web Start support in GlassFish. There has been some confusion about the enabled/disabled state as displayed and set via the admin console. That's why I urge you to check for the log message in server.log.

ianblav
Offline
Joined: 2012-10-24

G'day Tim,

You said that you have the same version of Java on the server and client side. Does this mean you are using separate systems for the client and server?

I've tried it both ways - on the combined NetBeans/Glassfish host using http://localhost:8080/CLTClient4 and on another host on the local network using http://Canberra.local:8080/CLTClient4. No difference. (CLTClient4 is the name of the app and is the context root from the log - see below.)

If so, then the problem might come from using "localhost" in the host name when the client is being launched. If the GlassFish server is not running on localhost then Java Web Start will be unable to retrieve the required files (including the JNLP document) from localhost:8080.

Understood. See above.

My suggestion: If you have successfully deployed the app then the server.log will contain a message that tells what the path (that is, the URL excluding the host and port) for launching the app client.

Messages are:
INFO: ACDEPL104: Java Web Start services stopped for the app client CLTClient4
INFO: ACDEPL103: Java Web Start services started for the app client CLTClient4 (contextRoot: /CLTClient4)
INFO: CLTClient4 was successfully deployed in 310 milliseconds.

I invoke the app with http://localhost:8080/CLTClient4 or http://Canberra.local:8080/CLTClient4, as appropriate (see above). In both cases Safari shows the successful download of a JNLP file so
I'm pretty confident the addressing of the app is okay.

If the GlassFish server is running on server X then from any system with Java (and therefore Java Web Start installed) you should be able to launch the client using this command:
javaws "http://X:8080/path-to-client"
where 'path-to-client' is the path from the server.log file. (I am assuming here that you are using the default HTTP port of 8080. If you have customized GlassFish to use another port then specify that port in the javaws URL.)

The port is standard 8080 as above. Running javaws at the command line as above produces the same result as attempting to run the app from the browser - same FileNotFoundException for the same file. This is so on the combined NetBeans/Glassfish host and a 2nd host on the local network (substituting the name of Glassfish host for localhost in the call of course). The latter call wraps the FileNotFound exception in a FailedDownloadException is the only difference - the resource that failed to download is the same jnlp file we are talking about. On the 2nd host I also deliberately tried a few wrong calls to make sure they give different errors, which they do. So again I am pretty happy that the addressing is okay.

If you don't see such a message in the server.log file then the deployment was done in a way that does not enable Java Web Start support for the client(s) in that app.

There is a message (see above) and after the redeploying the application as described in the original posting I can see in the admin server that JWS is enabled.

Launching this way (using the javaws command) simplifies things by taking some moving parts out of the picture (NetBeans, the admin console).
Please try that and let us know what you find.

Done as above. Note that in attempts above, online or command line, local host or remote host (excepting the deliberate errors), the result is a dialog box that contains the exception, wrapped exception (if there is one), and the launch file. There is always a launch file. I didn't check every one but those launch files I did check correctly name the target app - CLTClient4.

P.S. Yes, I'm aware that GlassFish provides automatic Java Web Start support for app clients. I'm the engineer who built the Java Web Start support in GlassFish. There has been some confusion about the enabled/disabled state as displayed and set via the admin console. That's why I urge you to check for the log message in server.log.

Understood. Certainly in my case after NetBeans deployment JWS does not show as enabled in the admin server. I can get the app server to show enabled by the undeploy, deploy, redeploy sequence as described. My nagging concern with JWS not showing as enabled after NetBeans deployment is: is the NetBeans deployment incomplete in some sense. From the perspective I think it would be worth getting the display to show JWS enablement after the NetBeans deployment.

P.S. Being the said engineer you might also be interested in my other recent post about Java web start: "Application client wont execute via Java webstart - XML$Password does not have a no-arg default constructor" of 25th October

-- Ian

tjquinn
Offline
Joined: 2005-03-30

Hello, again, Ian.

The absence of errors in the server.log means that GlassFish is able to find and serve any JNLP document it is asked for.

Let's try two things.

1. Please check the server system's /etc/hosts file to make sure there is nothing odd there.
2. in the domain's config directory please edit logging.properties and add this line:

javax.enterprise.system.container.appclient.level=FINER

This should cause some helpful information to appear in the server.log file when you attempt to launch the client using Java Web Start. Among other things it will show what files are being requested and how the system responds.

If it's OK with you let's take this discussion off-line and exchange e-mail directly. Once we know what the problem and solution were we can report our findings back here. You can e-mail me at tjquinn at java dot net.

- Tim