I've got a jar file that I'm loading with Java's Web Start. When I load the
..jnlp file from a browser, the application installs and runs properly the
first time. If I close the application and click on the link in the browser
a second time, the Web Start splash screen loads for 15-20 seconds and
disappears without launching the app. If I delete the application from the
Web Start utility it will again download and execute the first time but not
subsequently.

Web Start is configured to "Use Browser Settings" under Network Settings.
I've tried Direct Connection also. The results are the same under Mozilla
Firefox and IE 6.0. JRE's for 1.4.2_12, 1.5.0_06 and 1.5.0_11 are installed
with only 1.5.0_11 enabled currently.

Any thoughts?

Thanks,
-Keith

Keith McCutcheon wrote:

>I've got a jar file that I'm loading with Java's Web Start.

...

>Any thoughts?

- validate the JNLP
- post the link to the JNLP to the group, or failing that..
- post the JNLP content to the group.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via http://www.javakb.com

"Andrew Thompson" <u32984@uwewrote in message news:7113520b708e1@uwe...

- validate the JNLP
- post the link to the JNLP to the group, or failing that..
- post the JNLP content to the group.
>

Thanks, here it is....

The html and jnlp files are in c:\WebStart. The jar named Aspect7.jar is in
c:\WebStart\JarFile. The html file just contains a link to the jnlp file.

I downloaded JRE 1.6.x after posting the message and it works properly. I'd
still like to know how to deploy to users who don't yet have 1.6.

<!-- JNLP File -->
<!--jnlp spec="1.0+" codebase="file:///WebStart"
href="file:///WebStart/Aspect7.jnlp"-->
<jnlp>
<information>
<title>title</title>
<vendor>vendor.</vendor>
<description>description</description>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.4+"/>
<jar href="file:///WebStart/JarFile/Aspect7.jar"/>
</resources>
<application-desc main-class="aspect.Aspect">
</application-desc>
</jnlp>

Keith McCutcheon wrote:
...

..

>The html and jnlp files are in c:\WebStart. The jar named Aspect7.jar is in
>c:\WebStart\JarFile. The html file just contains a link to the jnlp file.

...

><!-- JNLP File -->
><!--jnlp spec="1.0+" codebase="file:///WebStart"
>href="file:///WebStart/Aspect7.jnlp"-->

I am not used to seeing a plain 'jnlp' element like ..

><jnlp>

..this, though the DTD suggests it should be OK.
OTOH, those paths look decidedly wrong.
Here is an example URL for a file on the D: drive
of my local system.

file:/D:/projects/TellURL.java

Note that the drive volume is listed as part of the URL.

I suggest reinstating the commented version of the JNLP
element, but like this.

<jnlp spec="1.0+"
codebase="file:/C:/WebStart"
href="Aspect7.jnlp>

With the jar HREF changed from this..

<jar href="file:///WebStart/JarFile/Aspect7.jar"/>

..to this.

<jar href="JarFile/Aspect7.jar"/>

The jar & JNLP HREF's are paths relative to the
codebase..

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via http://www.javakb.com

Keith McCutcheon wrote:
...

>I downloaded JRE 1.6.x after posting the message and it works properly. I'd
>still like to know how to deploy to users who don't yet have 1.6.

...

<j2se version="1.4+"/>

To do further testing with 1.4 - it will be necessary to
change this version attribute. See this document for tips..
<http://www.physci.org/jws/version.html ..with particular
reference to the sections on 'earlier major release' and
'prompted for download'.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.asp...neral/200704/1

I suggest reinstating the commented version of the JNLP

element, but like this.

Arrrgggg....

I was looking at it so long I wasn't even seeing that I had commented out
the original jnlp tag. I just needed a fresh set of eyes.

I removed the comment and it works properly, even on my old Win98 machine
with jre1.4.

Thanks much!

Andrew Thompson wrote:

OTOH, those paths look decidedly wrong.
Here is an example URL for a file on the D: drive
of my local system.
>
file:/D:/projects/TellURL.java
>

Actually the url's were correct and yours is wrong :-)
From RFC 1738 (Uniform Resource Locators) section 3.10:

3.10 FILES

The file URL scheme is used to designate files accessible on a
particular host computer. This scheme, unlike most other URL schemes,
does not designate a resource that is universally accessible over the
Internet.

A file URL takes the form:

file://<host>/<path>

where <hostis the fully qualified domain name of the system on
which the <pathis accessible, and <pathis a hierarchical
directory path of the form <directory>/<directory>/.../<name>.

For example, a VMS file

DISK$USER:[MY.NOTES]NOTE123456.TXT

might become

<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

As a special case, <hostcan be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.

The file URL scheme is unusual in that it does not specify an
Internet protocol or access method for such files; as such, its
utility in network protocols between hosts is limited.

Keith McCutcheon wrote:

...

>I was looking at it so long I wasn't even seeing that I had commented out
>the original jnlp tag. I just needed a fresh set of eyes.

Usenet is very handy for that.

>I removed the comment and it works properly, even on my old Win98 machine
>with jre1.4.

Glad to hear you sorted it. :-)

>Thanks much!

You're welcome.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.asp...neral/200704/1

Robert Larsen wrote:

>
>Actually the url's were correct and yours is wrong :-)

(snip RFC 1738 detail)

Interesting, but... The URL shown above, is what
Java printed out when I ran the code. Are you
saying Java's handling of URL's is buggy*?

* That would not entirely surprise me, there was the
entire matter of deprecating File.toURL() over toURI()
(though in this instance - I am seeing exactly the
same output for both).

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.asp...neral/200704/1

Andrew Thompson wrote:

Robert Larsen wrote:

>
(snip RFC 1738 detail)
>
Interesting, but... The URL shown above, is what
Java printed out when I ran the code. Are you
saying Java's handling of URL's is buggy*?
>
* That would not entirely surprise me, there was the
entire matter of deprecating File.toURL() over toURI()
(though in this instance - I am seeing exactly the
same output for both).
>

It seems so:
robert-desktop:~/code $ cat Test.java
import java.net.URL;
import java.net.URI;
public class Test {
public static void main(String args[]) throws Exception {
System.out.println(new URL("file:///home/robert"));
System.out.println(new URI("file:///home/robert"));
}
}
robert-desktop:~/code $ javac Test.java
robert-desktop:~/code $ java Test
file:/home/robert
file:///home/robert
robert-desktop:~/code $

I have never had problems using file:///some/path URL objects so Java
probably handles them correctly but prints them out wrong.

Andrew Thompson wrote:

Robert Larsen wrote:

Andrew Thompson wrote:

Interesting, but... The URL shown above, is what Java printed out when I ran the code. Are you saying Java's handling of URL's is buggy*?

It's the number of slashes after the protocol colon ("file://" vs. "file:/")
that's at issue here, right?

--
Lew

Lew wrote:

>Andrew Thompson wrote:

>

>
>Andrew Thompson wrote:

>
>It's the number of slashes after the protocol colon ("file://" vs. "file:/")
>that's at issue here, right?

That is part of what I find confusing, but I am also
a little unclear on whether 'home' (in Robert's example)
represents a drive. If not, how does whatever is resolving
the URL know where to start?

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.asp...neral/200704/1

Andrew Thompson wrote:

Lew wrote:

>
That is part of what I find confusing, but I am also
a little unclear on whether 'home' (in Robert's example)
represents a drive. If not, how does whatever is resolving
the URL know where to start?

Referencing: "file:///home/robert". Only the first two slashes are part of
the protocol string.

The third slash is the root "/" of the file system, so it starts at "/".

In the case of Windows, it treats "C:" as a path element. The file: URLs for
that drive should look like
file:///C:/directory/.../whatever
since in Windows the "root" is imaginary and just ahead of the drive letter.

--
Lew

Andrew Thompson wrote:

Lew wrote:

>
That is part of what I find confusing, but I am also
a little unclear on whether 'home' (in Robert's example)
represents a drive. If not, how does whatever is resolving
the URL know where to start?
>

That is a little confusing for people used to Windows. In Unix/Linux
there is no such thing as drive letters. There is only one "drive" and
all filesystems are made available through it.
The top level directory (or root directory) is called '/' (the third '/'
in the file url) and other filesystems (partitions, hard disks, CD
drives, etc.) are mounted (made accessible) through some empty directory
usually in "/mnt" or "/media". I have my CD drive in "/media/cdrom" and
an external USB drive in "/media/usb".
In the case of "/home/robert" I am saying that "home" is a directory
that can be accessed from the top level directory ("/") and that it
includes either a file or directory called "robert" which is actually my
home directory.
For Windows the same would probably be something like:
file://c:/documents and settings/robert

Robert Larsen wrote:

For Windows the same would probably be something like:
file://c:/documents and settings/robert

file:///c:/Documents%20and%20Settings/robert

The first two slashes after the protocol are required by the URL format. The
third one starts the actual file reference.

--
Lew