Trouble launching my Java Webstart application using JRE1.6
I have been investigating an issue and would appreciate any advice.
We were using JRE 1.5 and our JavaWebStart based apps worked fine. I then installed JRE 1.6 in my PC (windows). Now I can not launch apps using JRE 1.6.
Following are the details:
I downloaded J2SE 1.6 on my machine, Java webstart automatically started using that version to launch application. In order that the apps continued to be launched using JRE 1.5 (without uninstalling J2SE1.6) I unabled 1.6 (under control panel >Java) so that JWS would use JRE1.5, the apps still launched using JRE1.6. I then changed the launch.jnlp file specifying that it used version 1.5 but the apps still launched using 1.6. This the information I found upon investigating:
"Prior to 5.0 Update 6, an applet could specify the version of the JRE on which it would run. With 5.0 Update 6 and later installed on the Windows platform, all applets are executed with the latest version of the JRE."
(http://sunsolve.sun.com/search/document.do?assetkey=1-26-102557-1)
Does anyone know if the above is correct as well for Webstart apps?
So far, to avoid having to add signatures to every jar file for applications accessed via our intranet, we edited the javaws.policy (under Program Files\Java\jre1.5.0_06\lib\security) as follows (the last two lines of code are the ones we added to the generic policy file):
// @(#)javaws.policy1.7 00/09/18
grant codeBase"file:${jnlpx.home}/javaws.jar"{
permission java.security.AllPermission;
};
grant codeBase"file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dapps.ourcompany.com/-"{
permission java.security.AllPermission;
};
Is it true that in JRE1.6, all jar files required to be signed in order for an application to be launched? If so is there a way around it?
[2084 byte] By [
pan1234a] at [2007-11-27 7:49:47]
# 1
> ..to avoid having to add signatures to every jar file ..
Note that using an Ant build script* and a
self signed certificate, it is fairly simple to
sign a bunch of jar files.
* Ant has a SignJar task as well.
> ..Now I can not launch apps using JRE 1.6.
Why? What is wrong with launching the apps.
using 1.6 - what fails?
In relation to..
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102557-1
> Does anyone know if the above is correct as well for Webstart apps?
That quote you had was the 'applet in a browser'
section. The web start section says..
Java Web Start:
..
"Prior to 5.0 Update 6, an application could specify the
version of the JRE on which it would run. With 5.0 Update
6 and later installed, unsigned Java Web Start applications
that specify a version other than the latest installed will
trigger a warning, requiring explicit user permission
before the application will run. Signed Java Web Start
applications are not affected."
So. Even unsigned web start apps. and applets seem
to be able to request an earlier version, it is just that it
will prompt the user WTE..
"This application has requested
an earlier version, OK?"
> Is it true that in JRE1.6, all jar files required to be
signed in order for an application to be launched?
Certainly not. I have a number of examples here..
http://www.physci.org/jws/
All the JNLP API examples at the top of the page
are sandboxed and the Jar's not signed. They
work just fine for me in 1.6.
As far as trusted applications and permissions
go, I would strongly recommend the Ant SignJar
task over editing policy files. At least it keeps the
control in one place, at the application build side.
You just need to get the users used to 'clicking
through' the self signed certificate for the launch.
# 2
The only problem here is that the grant of all-permissions in the policy file only grants permissions to the jar files in the 1.5.0 version of the java web start cache.
grant codeBase "file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dapps.ourcompany.com/-" {
permission java.security.AllPermission;
};
In 1.6, the cache location and format have both changed (cache implementation has been merged with Java plug-in.)
If you must edit the java.policy files, you will have to alos add the actual host codebase for it to work with 1.6:
grant codeBase "file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dapps.ourcompany.com/-" {
permission java.security.AllPermission;
};
grant codeBase "http://yourcompan.com/codebase/-" {
permission java.security.AllPermission;
};
/Andy
# 3
Thanks Andy for your reply and the information.
As per your advice, I added the following codes (last 2 lines) to the javaws.policy file:
// // @(#)javaws.policy1.7 00/09/18
grant codeBase "file:${jnlpx.home}/javaws.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dapps.eogresources.com/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dlocalhost/-" {
permission java.security.AllPermission;
};
The follwing happen when I launched the application:
1. A security message appeared asking for permission to access our authentication server.
2. When I clicked OK, a login status message appeared with the following error message - '"The application server is unavailable".
I then changed the codes to make it similar to the codes you had suggested:
// @(#)javaws.policy1.7 00/09/18
grant codeBase "file:${jnlpx.home}/javaws.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.home}/Application Data/Sun/Java/Deployment/cache/javaws/http/Dapps.ourcompany.com/-" {
permission java.security.AllPermission;
};
grant codeBase "http://localhost/codebase/-" {
permission java.security.AllPermission;
};
The application still failed to launch.
Any help will be very much appreciated.
# 4
> Certainly not. I have a number of examples here..
> http://www.physci.org/jws/
> All the JNLP API examples at the top of the page
> are sandboxed and the Jar's not signed. They
> work just fine for me in 1.6.
Great. But I'm pretty sure the poster is asking in regards to code that has to run outside the sandbox, hence requests for info regarding granting all permissions in the policy file.
> As far as trusted applications and permissions
> go, I would strongly recommend the Ant SignJar
> task over editing policy files. At least it keeps
> the
> control in one place, at the application build side.
> You just need to get the users used to 'clicking
> through' the self signed certificate for the launch.
The idea that you would have all of your application users get 'used to clicking through the self signed certificate' every time they launch one of your apps, particularly if you are behind a firewall and are only using them on an intranet, is preposterous. Presumably the reason the topic was posted was to avoid that very thing. The question, as far as I can tell, seems to be if you can allow outside-the-sandbox without signing all the jar files, which you COULD do in WebStart 1.5 by editing the javaws.policy file, but which does not seem to be as straightforward in 1.6.
# 5
Thanks for your reply. I think you have got the gist of my query.
All our apps are accessed via the Intranet and therefore I'm sure getting users to click through the self signed certificate for apps which previously (in JRE 1.5) they could access easily without this procedure could create some annoyance.
As Andy has posted, I think one of the issue here is that the location for the cache folder has been changed (in 1.6) and therefore I need to change our javaws.policy file to redirect it to the new cache folder location.
Does anyone have any idea where the cache folder resides in 1.6?
Also in 1.6, I think the format of downloaded jar files change in the cache folder.
Does anyone know what the effects of that would be on the launch of the apps and if that's problematic, what is the solution?
As always I really appreciate your help.
# 6
> Does anyone have any idea where the cache folder resides in 1.6?
On Win XP with Java 6.
Start | Settings | Control Panel | Java
General (tab) |
Temporary Internet Files (bordered region) |
Temporary Files Settings (dialog) }
Location (bordered region) |
Change (button)
Put it on a known path of your choosing..
> Also in 1.6, I think the format of downloaded jar files change in the cache folder.
>
> Does anyone know what the effects of that would be on the launch of the apps and if that's problematic, what is the solution?
AFAIU - there was a major change between 5
and 6 in that Sun merged the applet and web
start caches. Sun reserves the right to
change cache locations any time it likes.
Other matters which might affect cache paths
and names are (I suspect) the ..
Disk Space (bordered region) |
'Select the Compression Level for JAR files:' (select)
If you can lock that and the cache location down,
perhaps you can minimise the chance of the
resource path/names changing.
# 7
Thanks for your reply Andrew.
Going back to my initial question, does anyone know if it possible to carry on using unsigned jar files to launch our webstart apps in JRE 1.6 (for codes that run outside the sandbox)?
We were able to do this in WebStart 1.5 by editing the javaws.policy file (please refer to my previous post for the codes), but we're struggling to do the same in 1.6.
Thanks
# 8
I do the same thing with the deployment files using a trojan horse signed jnlp file. I am having all sorts of trouble with 1.6/Vista/IE 7 though. But anyway, I wanted to let you know that you are not alone in your troubles with 1.6, and wanted to back you up in your modifying of the deployment.properties. Signing jars on a big app stinks.
We started out signing all our jars in 1.2.2/webstart, but it had a huge performance and size penalty so we had to switch to having the trojan. I already auto discover the cache location (because of previous changes of cache location in 1.4) by finding where my jar is downloaded, so hopefully I am OK there (although I read somewhere else that a change in the class loader may mess up my determination of where the cache is).
Anyway, I'm working on this too, so I'll let you know if I figure it out. I still have to get my admin-less JRE installer to work first. 1.6 has screwed that up too somehow (see my other post if interested).
# 9
Thanks a ton for your insight. Please keep me updated with your progress and I will too.Thanks......Pan
