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
--
[Message sent by forum member 'ianblav']
View Post: http://forums.java.net/node/891985