Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Webstart broken: Bad installation. No JRE found in configuration file
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Webstart broken: Bad installation. No JRE found in configuration file



I found that, in the ~/Library/Caches/Java/deployment.properties file, if I changed the following entries,

deployment.javaws.jre.0.osarch=i386
deployment.javaws.jre.1.osarch=i386
deployment.javaws.jre.2.osarch=i386

to these:

deployment.javaws.jre.0.osarch=ppc
deployment.javaws.jre.1.osarch=ppc
deployment.javaws.jre.2.osarch=ppc

everything works. This is even though I have an x86 Mac (with the 1.6.0-dp-b88-34 preview installed).
These changes are also retained after changing the Java Application Runtime Settings order using the 'Java SE 6 > Java Preferences' app.


p.s. Have just submitted the above as a bug report.

On 14 Jun 2007, at 13:06, David Clunie wrote:

Hi Scott

I seem to have a similar problem, except that it causes a conflict
between the version of javac used and webstart. I can't get both
to work with the same settings.

Specifically, after installing javase6release1dp6, if I run the
Java SE 6>Java Preferences and change the order of the Java
Application Runtime Settings to put Java SE 6 first, then web
start breaks with the "Bad installation. No JRE found in configuration
file" message, but javac -version returns "javac 1.6.0-dp" and
works.

The only way I can get webstart to work is if the "deployment.properties"
file is removed from the user's Library/Caches/Java folder, but then
the javac version that gets involved is 1.4.2.


As Joshua says, any use of Java Preferences that changes the order
of the Java Application Runtime Settings causes web start to fail.

I presume that when web start is "working" in this manner, that it is
also using the 1.4.2 JRE by default, which is also not what is needed.

If one takes a look at the "deployment.properties" file generated by Java
Preferences, there doesn't seem to be anything obviously wrong with it,
and all the paths exist, etc.


% sort Library/Caches/Java/deployment.properties
#Java Plugin jre's
#Java Web Start jre's
#Thu Jun 14 07:56:52 EDT 2007
#Thu Jun 14 07:56:52 EDT 2007
#Thu Jun 14 07:56:52 EDT 2007
#deployment.properties
deployment.apple.special=true
deployment.browser.path=/Applications/Safari.app
deployment.javapi.cache.update=true
deployment.javapi.jre.1.4.2.args=
deployment.javapi.jre.1.4.2.osarch=i386
deployment.javapi.jre.1.4.2.osname=Mac OS X
deployment.javapi.jre.1.4.2.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.4.2/Home
deployment.javapi.jre.1.5.0.args=
deployment.javapi.jre.1.5.0.osarch=i386
deployment.javapi.jre.1.5.0.osname=Mac OS X
deployment.javapi.jre.1.5.0.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.5.0/Home
deployment.javapi.jre.1.6.0.args=
deployment.javapi.jre.1.6.0.osarch=i386
deployment.javapi.jre.1.6.0.osname=Mac OS X
deployment.javapi.jre.1.6.0.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.6.0/Home
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.location=http\://java.sun.com/products/ autodl/j2se
deployment.javaws.jre.0.osarch=i386
deployment.javaws.jre.0.osname=Mac OS X
deployment.javaws.jre.0.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.6.0/Home/bin/java
deployment.javaws.jre.0.platform=1.6
deployment.javaws.jre.0.product=1.6.0
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.1.enabled=true
deployment.javaws.jre.1.location=http\://java.sun.com/products/ autodl/j2se
deployment.javaws.jre.1.osarch=i386
deployment.javaws.jre.1.osname=Mac OS X
deployment.javaws.jre.1.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.5.0/Home/bin/java
deployment.javaws.jre.1.platform=1.5
deployment.javaws.jre.1.product=1.5.0
deployment.javaws.jre.1.registered=true
deployment.javaws.jre.2.enabled=true
deployment.javaws.jre.2.location=http\://java.sun.com/products/ autodl/j2se
deployment.javaws.jre.2.osarch=i386
deployment.javaws.jre.2.osname=Mac OS X
deployment.javaws.jre.2.path=/System/Library/Frameworks/ JavaVM.framework/Versions/1.4.2/Home/bin/java
deployment.javaws.jre.2.platform=1.4
deployment.javaws.jre.2.product=1.4.2
deployment.javaws.jre.2.registered=true
deployment.javaws.splash.index=/Users/dclunie/Library/Caches/Java/ cache/6.0/splash/splash.xml
deployment.version=6.0


David

Joshua Marinacci wrote:
Yeah. It's 11.6.0. But it was that before. I did some more testing and
discovered it is not the restart that did it. It's changing the order of
Java versions in the "Java Application Runtime Settings". Changing the
order at all, either to make Java 6 first or not first, seems to break
things. Deleting the deployment.properties always fixes it.


- Josh


On Feb 12, 2007, at 11:36 AM, Scott Kovatch wrote:

Do a Get Info on one of your JNLP files and verify which version of
Java Cache Viewer is opening the file. Then make sure all JNLP files
are being opened by Java 6's version of Java Cache Viewer.app. Get
Info will tell you that "Java Cache Viewer.app" will open the file,
but not which version of the app will open it. If you're using Java 6,
you want version 11.6.0.


There's also the possibility that there's just some previously- unfound
bug in Java 6's Cache Viewer.


Scott

On Feb 12, 2007, at 11:53 AM, Joshua Marinacci wrote:

Ok, this is getting really weird. The problem has come back. I can
fix it again, but I'm not sure why this is happening.  I'm starting
to think it breaks after I restart my computer, which I did for the
first time in weeks yesterday.

- J


On Feb 8, 2007, at 1:43 AM, Joshua Marinacci wrote:

Yup. that seems to have done it.  I then got an interesting dialog
I'd never seen before. I says it is upgrading my application cache
to Java 6.  Everything works now. Thanks.

I'm curious why installing Java 6 again didn't set it back, though.

- Josh

On Feb 7, 2007, at 2:53 PM, Scott Kovatch wrote:

Move aside your deployment.properties file in ~/Library/Caches/ Java
and then make sure that the 1.6 version of Java Cache Viewer is the
default application for handling JNLP files.


I _think_ what's happening is that it's a case of 'last one wins',
so if you installed the Java 5 developer preview its version of
Java Cache Viewer claimed JNLP files and LaunchServices made it the
default.


Scott

On Feb 7, 2007, at 2:59 PM, Joshua Marinacci wrote:

I saw that someone else has had this same problem when trying to
launch webstart apps from the browser or desktop/ When I download
a JNLP and double click it I get this error in the console:


Java Web Start splash screen process exiting .....
    Bad installation. No JRE found in configuration file


Running the jnlp manually using 'javaws' from the command line
works fine, though. I'm not positive, though I'm pretty sure, that
this started when I installed the latest Java 5.0 developer
release. I just tried downloading 1.6 again and re-installing it,
as well as switching the preferred JVM version back and forth; all
to no avail.


I tried changing the preferred app for .jnlp files to webstart
from the cache viewer and now I can get it to load. This doesn't
seem right, however. It's using the 1.4.2 version of the webstart
client, even though it's actually invoking my app using 1.6 (as I
requested). Since it's using an older version of the client that
means I get the old splashscreen, the old security dialogs, and no
support for the newer JNLP spec. Is there a way to launch things
again with the 1.6 webstart launcher?



Thanks, Josh
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden




Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.