By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,602 Members | 1,507 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,602 IT Pros & Developers. It's quick & easy.

Java Web Start

P: n/a
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
Apr 22 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
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

Apr 22 '07 #2

P: n/a
"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>
Apr 22 '07 #3

P: n/a
Keith McCutcheon wrote:
...
>- post the JNLP content to the group.
..
>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

Apr 22 '07 #4

P: n/a
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

Apr 22 '07 #5

P: n/a
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!

Apr 22 '07 #6

P: n/a
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.
Apr 23 '07 #7

P: n/a
Keith McCutcheon wrote:
>I suggest reinstating the commented version of the JNLP
element, ...
...
>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

Apr 23 '07 #8

P: n/a
Robert Larsen 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 :-)
(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

Apr 23 '07 #9

P: n/a
Andrew Thompson wrote:
Robert Larsen 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 :-)

(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.
Apr 23 '07 #10

P: n/a
Lew
Andrew Thompson wrote:
>>file:/D:/projects/TellURL.java
Robert Larsen wrote:
>Actually the url's were correct and yours is wrong :-)
(snip RFC 1738 detail)
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
Apr 23 '07 #11

P: n/a
Lew wrote:
>Andrew Thompson wrote:
>>>file:/D:/projects/TellURL.java
>>Actually the url's were correct and yours is wrong :-)
(snip RFC 1738 detail)

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?
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

Apr 23 '07 #12

P: n/a
Lew
Andrew Thompson wrote:
Lew wrote:
>Andrew Thompson wrote:
>>>>file:/D:/projects/TellURL.java
Actually the url's were correct and yours is wrong :-)
(snip RFC 1738 detail)
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?

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
Apr 24 '07 #13

P: n/a
Andrew Thompson wrote:
Lew wrote:
>Andrew Thompson wrote:
>>>>file:/D:/projects/TellURL.java
Actually the url's were correct and yours is wrong :-)
(snip RFC 1738 detail)
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?

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
Apr 24 '07 #14

P: n/a
Lew
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
Apr 24 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.