Where is javaws.exe??

[Paul Lutus]

this gives:

javaws is an external : C:\Program
Files\Java\j2re1.4.2_01\javaws\javaws.exe

However, that is not on the path. It is not an alias. How the heck is
it finding it?

Create a Perl utility that:

1. Splits the path into individual directories, and

2. Searches each path component for the executable.

 

[Dale King]

I have finally figured out how to install Java web start apps from CD.

The details are at http://mindprod.com/jgloss/javawebstart.html

Why do you keep insisting on publishing erroneous and misleading information
about WebStart?

- "you must also talk to the ISP who hosts your website to set up
associations from extension to MIME type for all the Java file types such as
..class , .java , .jar , .jnlp , .jardiff and .ser" Not true. The only one
that is necessary is .jnlp.
- "Unsigned applications have to use the Mickey Mouse PersistenceService
APIs". Once again there is nothing Mickey Mouse about the PersistanceService
APIs. They do exactly what they were designed to do. Your issue is that you
want them to use them for something other than they were designed to do.
- "Why not just use regular files that way any sane programmer would?"
Because it would be a huge security hole to allow unsigned applications to
do so.
- "There has been almost no cleverness applied to make the updates compact"
That's what jardiff is for.
- "It may be yet another orphaned product." Here is a link to a talk on
upcoming changes for 1.5:
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1486.en.jsp
- "It requires custom code running on the ISP to properly serve the jar
files." No, just the mime type for .jnlp. It only requires custom code to do
things like jardiff.
- "The proper solution to the CD install problem is for Sun to support
codebase="cd"." There is a fix in the works for 1.5, see the above link.

 

[Roedy Green]

The only one
that is necessary is .jnlp.

Will correct. However , the problem is getting your ISP to fix ANY
MIME type. While you are at it you, might as well get all the Java
MIME types fixed. If you are doing a website about Java you will want
those others as well.

 

[Roedy Green]

"Unsigned applications have to use the Mickey Mouse PersistenceService
APIs". Once again there is nothing Mickey Mouse about the PersistanceService
APIs. They do exactly what they were designed to do. Your issue is that you
want them to use them for something other than they were designed to do.

How about an example of use and then let the audience be a judge if
they are Mickey Mouse.

 

[Roedy Green]

- "Why not just use regular files that way any sane programmer would?"
Because it would be a huge security hole to allow unsigned applications to
do so.

If the JWS sandbox gave a small piece of disk real estate to work in,
you could have persistence simply, and persistence easy to back up and
restore.

 

[Roedy Green]

- "There has been almost no cleverness applied to make the updates compact"
That's what jardiff is for.

That was designed to ensure it was never used. It requires server side
special code. It requires fooling around creating special jars
manually. Nobody actually uses it.

 

[Roedy Green]

- "It may be yet another orphaned product."

quoting out of context:

It has not changed much since its initial release. It may be yet
another orphaned product. It does not deserve to be. However, Sun has
just released a new beta 1.2 after a year or so of nothing happening,
so we'll see if it is picking up steam again.

 

[Roedy Green]

- "It requires custom code running on the ISP to properly serve the jar
files." No, just the mime type for .jnlp. It only requires custom code to do
things like jardiff.

That's why I used the term "properly".

 

[Roedy Green]

There is a fix in the works for 1.5, see the above link.

the new kludge won't work unless they put a javaws.exe kicker on the
path .

 

[Dale King]

Will correct. However , the problem is getting your ISP to fix ANY
MIME type. While you are at it you, might as well get all the Java
MIME types fixed. If you are doing a website about Java you will want
those others as well.

That is true. I have never gotten my ISP to do it. I really wish Sun would
remove that stupid restriction and look at the file to see if it is a valid
JNLP file rather than worrying about the MIME type.

 

[Dale King]

If the JWS sandbox gave a small piece of disk real estate to work in,
you could have persistence simply, and persistence easy to back up and
restore.

And open up huge security holes that allow the app to write to the disk.

 

[Dale King]

quoting out of context:

It has not changed much since its initial release. It may be yet
another orphaned product. It does not deserve to be. However, Sun has
just released a new beta 1.2 after a year or so of nothing happening,
so we'll see if it is picking up steam again.

And the context was removed because it provided no additional pertinent
information. It is not an orphaned product. 1.2 is not in beta it is in
production and the current release is 1.4.2 not 1.2. I posted a link to
changes coming in 1.5. It has been changing and there are future planned
improvements. There is no reason to claim that it may be an orphaned
product.

And you need to separate out Java WebStart the product and JNLP the
protocol. If Sun dropped WebStart tomorrow that does not mean that JNLP goes
away. JNLP is a spec that others besides Sun can and have implemented.

 

[Dale King]

That's why I used the term "properly".

That depends on the application. A small application can easily be served
with no custom code on the server.

 

[Dale King]

How about an example of use and then let the audience be a judge if
they are Mickey Mouse.

I have attached my implementation of a PreferencesFactory that uses the JNLP
persistence service as the backing store. The goal ot the PersistenceService
is to allow an application to store data on the client and to access that
data later in the same or a different incarnation of the app. That is all it
was designed to do.

It was *NOT* designed as a means for an application to store data on the
client for use by other applications on the client or for the user to access
the information directly. That is why the manner in which the data is stored
on the client is completely at the discretion of the JNLP implementation.

Your problem with the PersistenceService is that you are trying to use it as
a means of storing data for other applications to use. It fails miserably at
that, because it was not designed for that purpose. That does not make it
MickeyMouse, it merely indicates that you are not using it for what it was
designed for.

You talk about the "Where are the files?" But you shouldn't care. That is
all specific to the implementation of the JNLP client software. You aren't
meant to access it yourself.

So here is my implementation of a JnlpPreferencesFactory. (Note there is a
problem with the Preferences implementation that makes substituting a
different preferences factory in JNLP something that cannot be done
transparently. This is a bug in Preferences in that it is using the system
boot loader and not a problem with PersistenceService).

public class JnlpPreferencesFactory implements PreferencesFactory
{
private final PersistenceService ps
=
PersistenceService)ServiceManager.lookup( "javax.jnlp.PersistenceService" );

private class JnlpPreferences extends AbstractPreferences
{
private FileContents contents = null;
private Properties props = null;

private final URL url;

public JnlpPreferences( URL url )
{
super( null, "" );
this.url = url;
}

public JnlpPreferences( JnlpPreferences parent, String name )
throws MalformedURLException
{
super( parent, name );
this.url = new URL( parent.url, name );
}

private Properties getProperties()
{
if( props == null )
{
props = new Properties();
try
{
ps.create( url, 8096 );
}
catch( IOException e )
{
}
try
{
contents = ps.get( url );

props.load( contents.getInputStream() );
}
catch( Exception e )
{
System.out.println( e );
}
}
return props;
}

protected String[] childrenNamesSpi() throws BackingStoreException
{
try
{
return ps.getNames( url );
}
catch( IOException e )
{
System.out.println( e );
throw new BackingStoreException( e );
}
}

protected AbstractPreferences childSpi( String name )
{
try
{
return new JnlpPreferences( this, name );
}
catch( MalformedURLException e )
{
System.out.println( e );
throw new Error( e );
}
}

protected void flushSpi() throws BackingStoreException
{
if( props != null )
{
try
{
props.store( contents.getOutputStream( true ), "" );
}
catch( IOException e )
{
System.out.println( e );
throw new BackingStoreException( e );
}
}
}

protected String getSpi( String key )
{
return getProperties().getProperty( key );
}

protected String[] keysSpi() throws BackingStoreException
{
return (String[])getProperties().keySet().toArray( new
String[ 0 ] );
}

protected void putSpi(String key, String value)
{
getProperties().put( key, value );

try
{
flushSpi();
}
catch( Exception e )
{
}
}

protected void removeNodeSpi() throws BackingStoreException
{
try
{
ps.delete( url );
}
catch( IOException e )
{
throw new BackingStoreException( e );
}
}

protected void removeSpi( String key )
{
getProperties().remove( key );
}

protected void syncSpi() throws BackingStoreException
{
flushSpi();
}
}

public final Preferences userRoot;

public Preferences systemRoot()
{
throw new IllegalAccessError( "System root not supported" );
}

public Preferences userRoot()
{
return userRoot;
}

public JnlpPreferencesFactory() throws UnavailableServiceException
{
BasicService bs
=
(BasicService)ServiceManager.lookup( "javax.jnlp.BasicService" );

URL codeBase = bs.getCodeBase();

userRoot = new JnlpPreferences( codeBase );
}
}

 

[Roedy Green]

ps.create( url, 8096 );

and what pray tell is that number.? This is the Mickey Mouse heart I
bitched about.

 

[Roedy Green]

I have attached my implementation of a PreferencesFactory t

you have there about 100 lines of bubblegum that manages to persist
one value. Does that not seem ridiculous to you?

This is like some fancy car door lock that manages to befuddle the
owner into locking himself out. It often keeps the owner out, but
always permits in professional thieves.

That bailing wire scheme is highly inconvenient and further it offers
no more security that had the unsigned app been told it could write
only X bytes of files in the current directory.

 

[Roedy Green]

And open up huge security holes that allow the app to write to the disk.

It is not a security hole if you put a limit on its size and give him
his own directory to play in and don't let him out.

The advantage is then JWS apps can function without modification as
ordinary apps, just by installing them with ZeroG or the like.

A malicious app can likely do more damage with the API presented by
filling it with junk. At least with a disk scheme, you could have a
clear quota controlled by the policy file.

 

[Roedy Green]

There is no reason to claim that it may be an orphaned
product.

There was at the time I wrote it.

 

[Bent C Dalager]

That is true. I have never gotten my ISP to do it. I really wish Sun would
remove that stupid restriction and look at the file to see if it is a valid
JNLP file rather than worrying about the MIME type.

How would this work? A JNLP file needs to have the correct mime type
for the browser and OS to find the java web start application with
which to start it. If it's just some random mime type, the browser
will either ask for a file to save it to or it'll show gibberish in
the browser window.

Cheers
Bent D

 

[Dale King]

How would this work? A JNLP file needs to have the correct mime type
for the browser and OS to find the java web start application with
which to start it. If it's just some random mime type, the browser
will either ask for a file to save it to or it'll show gibberish in
the browser window.

It would work off the file extension. If you have a web site that has a jnlp
file that returns a text mime type the browser is still smart enough to know
to open WebStart. Then Webstart rejects it because it isn't the right MIME
type. I've done it before.