WebStart Java 7 update 71 72 [message #1445462] |
Wed, 15 October 2014 13:18  |
Eclipse User |
|
|
|
Oracle just released java 7 update 71 and 72. This breaks my company's web-start RCP application.
Not sure what the classloading issue is. Not getting any messages about jar signing issues.
!SESSION Wed Oct 15 06:15:24 PDT 2014 ------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2014-10-15 06:15:24.966
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.NoClassDefFoundError: org.eclipse.osgi.util.NLS
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:79)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
|
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1446228 is a reply to message #1446155] |
Thu, 16 October 2014 14:28   |
Eclipse User |
|
|
|
It works for me (passing the property name="osgi.parentClassloader" value="current") - tried eclipse 3.7.2 with java7u71 - not using a signed jnlp nor template, setting securty to 'medium'.
You're right about the problem that jnlp properties need to start with "jnlp.": a solution for that has been described: it consists of making a wrapper like this
public class WrapperMain {
public static void main(String... args) {
java.util.Properties props = System.getProperties();
for (String key : props.stringPropertyNames()) {
if (key.startsWith("jnlp.")) {
System.setProperty(key.substring(5), props.getProperty(key));
}
}
org.eclipse.equinox.launcher.WebStartMain.main(args);
}
}
and prefixing all your properties...
<property name="jnlp.osgi.parentClassloader" value="current"/>
and invoke this one as your main class...
<application-desc main-class="com.yourcompany.WrapperMain">
<argument>-nosplash</argument>
</application-desc>
[Updated on: Thu, 16 October 2014 14:30] by Moderator Report message to a moderator
|
|
|
Re: WebStart Java 7 update 71 72 [message #1446298 is a reply to message #1446228] |
Thu, 16 October 2014 16:43   |
Eclipse User |
|
|
|
Dieter,
Thanks, that works. I packaged up this class in a new Fragment, with
Fragment-Host: org.eclipse.equinox.launcher
I appreciate your help!
I'm sort of waiting for the day that a Java update creates a truly fatal wound to my RCP application. Would love to find an alternative to Web Start.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1447133 is a reply to message #1445462] |
Fri, 17 October 2014 21:15   |
Eclipse User |
|
|
|
Unfortunately, setting the (jnlp.)osgi.parentClassLoader property didn't work for me. It did cause a change in the launching process, but it didn't fix it.
Without it I saw an AccessControlException in the web start trace, caused by EclipseLog.checkLogFileSize. With the property set, there are no errors in the web start trace, but now there's a ClassCircularityError on /org/eclipse/osgi/framework/util/SecureAction$19 in the eclipse log. The attempt to instantiate the class comes from org.eclipse.osgi.framework.internal.protocol.StreamHandlerFactory.createURLStreamHandler (StreamHandlerFactory.java:102). I'm using Eclipse 3.7 jars.
Right now the only "fix" for the problem I can give my customers is to have them uninstall any Java 7 or Java 8 JREs and (re)install Java 7 update 67. That release works with or without the parentClassLoader property. Of course, it exposes customers to the security holes Oracle supposedly patched in 7u71 and 8u25, but our product is generally used behind a firewall. We sign our jars properly so our customers can use the "Very High" security setting in Java 7 update 67 or Java 8 update 11.
This is the fourth Oracle update in two years that has broken our WebStart-based application. Management is now thinking of abandoning WebStart and perhaps even the OSGi platform in favor of a monolithic application with a bundled JRE that we'd require customers to distribute, configure, and install. That would be painful, but Oracle obviously doesn't care about automatically pushing out incompatible Java updates. I understand the need for security patches, but Oracle should at least provide a backward-compatibility option that customers can use at their own risk.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1451406 is a reply to message #1447133] |
Thu, 23 October 2014 19:49   |
Eclipse User |
|
|
|
Hi Barry,
We are in the exactly the same situation as you.
java.security.AccessControlException: access denied ("java.util.PropertyPermission" "eclipse.exitcode" "write")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at org.eclipse.osgi.framework.internal.core.FrameworkProperties.setProperty(FrameworkProperties.java:57)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:219)
Then adding the parent class path
<property name="jnlp.osgi.parentClassloader" value="current"/>
produced
java.lang.ClassCircularityError: org/eclipse/osgi/framework/util/SecureAction$19
at org.eclipse.osgi.framework.util.SecureAction.loadSystemClass(SecureAction.java:370)
at org.eclipse.osgi.framework.internal.protocol.StreamHandlerFactory.getBuiltIn(StreamHandlerFactory.java:82)
at org.eclipse.osgi.framework.internal.protocol.StreamHandlerFactory.createURLStreamHandler(StreamHandlerFactory.java:102)
at java.net.URL.getURLStreamHandler(Unknown Source)
I wonder if it was due to a warning we were getting regarding signed and unsigned jars when using 7u67, so I may explore that tomorrow?
We're banging our heads against wall, did you make any progress??
I'll try and share anything exciting we come across here....
Chris
|
|
|
Re: WebStart Java 7 update 71 72 [message #1453710 is a reply to message #1451406] |
Mon, 27 October 2014 11:02   |
Eclipse User |
|
|
|
We also get the error with update 71/72.
Quote:java.security.AccessControlException: access denied ("java.util.PropertyPermission" "eclipse.exitcode" "write") at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkProperties.setProperty(FrameworkProperties.java:57) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:219)
Prior to 71/72, we have retrieved no warnings/errors.
I'm going to add the property below to see what happens. Will find out today if it does anything useful.
Quote:<property name="jnlp.osgi.parentClassloader" value="current"/>
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1453938 is a reply to message #1453894] |
Mon, 27 October 2014 18:38   |
Eclipse User |
|
|
|
I guess that will be another thing to try.
So you only had to add
<property name="jnlp.cxn.eclipse.security" value="osgi"/>
and not
<property name="jnlp.osgi.parentClassloader" value="current"/>
or did you have to add both?
Thanks,
Jason
|
|
|
Re: WebStart Java 7 update 71 72 [message #1454007 is a reply to message #1445462] |
Mon, 27 October 2014 20:59   |
Eclipse User |
|
|
|
I just had to add
<property name="jnlp.cxn.eclipse.security" value="osgi"/>
and nothing else.
Note that the property name is prefixed to allow setting through jnlp. See Dieter Cailliau's reply for more information on this.
|
|
|
|
|
|
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1454589 is a reply to message #1445462] |
Tue, 28 October 2014 15:04   |
Eclipse User |
|
|
|
Hi,
We have been battling this problem for about a week now. We saw the updates to this thread this morning and tried adding :
<property name="jnlp.eclipse.security" value="osgi" /> to our jnlp file and removing <property name="jnlp.osgi.parentClassloader" value="current"/> that we had added previously.
This seems to have fixed the issue for us.
As we have spent so much time tearing our hair out we would be interested to know what it was that prompted you to try this in the first place?
|
|
|
Re: WebStart Java 7 update 71 72 [message #1454645 is a reply to message #1445462] |
Tue, 28 October 2014 16:08   |
Eclipse User |
|
|
|
When we were trying to determine what changed in the new versions of the JRE that caused the issue we noticed that applications launched from JWS now included the argument
This forces the default security policy on the application. Our guess was that this was interfering with the custom security policy that Equinox utilizes so we went in search of an eclipse runtime property that would let us set the security policy back to the custom one. "eclipse.security" is what we found.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1454772 is a reply to message #1454645] |
Tue, 28 October 2014 19:06   |
Eclipse User |
|
|
|
Weird. Adding that property doesn't appear to have worked for me. I'm still getting the following error.
!SESSION Tue Oct 28 14:56:14 EDT 2014 ------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2014-10-28 14:56:14.271
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.security.AccessControlException: access denied ("java.util.PropertyPermission" "eclipse.exitcode" "write")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at org.eclipse.osgi.framework.internal.core.FrameworkProperties.setProperty(FrameworkProperties.java:64)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:216)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:78)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:56)
at com.ourpackage.Main.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
This is what we have in the .jnlp file
<resources>
<j2se version="1.5+" />
<jar href="plugins/com.ourpackagename.jar"/>
<extension name="Wrappering feature" href="features/com.ourpackage_2.0.0.jnlp"/>
<property name="jnlp.osgi.instance.area" value="@user.home/Application Data/application/$$version"/>
<property name="jnlp.osgi.configuration.area" value="@user.home/Application Data/application/$$version"/>
<property name="jnlp.cxn.eclipse.security" value="osgi"/>
<property name="jnlp.eclipse.product" value="com.ourproduct"/>
</resources>
|
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1455434 is a reply to message #1454774] |
Wed, 29 October 2014 11:19   |
Eclipse User |
|
|
|
I seem to be getting the following error when using the property. We're currently using org.eclipse.osgi_3.3.2.R33x_v20080105.jar
This is how I have the property
<property name="jnlp.eclipse.security" value="osgi"/>
java.lang.NoClassDefFoundError: osgi
at org.eclipse.osgi.framework.internal.core.Framework.installSecurityManager(Framework.java:1441)
at org.eclipse.osgi.framework.internal.core.Framework.initialize(Framework.java:161)
at org.eclipse.osgi.framework.internal.core.Framework.<init>(Framework.java:147)
at org.eclipse.osgi.framework.internal.core.OSGi.createFramework(OSGi.java:90)
at org.eclipse.osgi.framework.internal.core.OSGi.<init>(OSGi.java:31)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:283)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:172)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:78)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.WebStartMain.main(WebStartMain.java:56)
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1456414 is a reply to message #1455441] |
Thu, 30 October 2014 10:31   |
Eclipse User |
|
|
|
After looking at the differences in source code between 3.3.2 and 3.8.1, I noticed 3.3.2 didn't have code in place for this property. I updated to the org.eclipse.osgi_3.8.1* version and the property and webstart now works for me.
Thanks,
Jason
|
|
|
Re: WebStart Java 7 update 71 72 [message #1463782 is a reply to message #1456414] |
Thu, 06 November 2014 23:02   |
Eclipse User |
|
|
|
I'll try the jnlp.eclipse.security property (with a wrapper that strips the jnlp prefix). But that would only fix the next release of our product.
For our customers who want to upgrade their JRE but who don't want to upgrade to a new version of our product, we found a solution is to distribute a keystore file containing the public key certificate for our jars. The customer can install the keystore file on our server. Customers must then edit the JRE policy file on the machine where they'll run the rich client. (For Java 7 on Windows using 32-bit browsers, the policy file is C:\Program Files (x86)\Java\jre7\lib\security\java.policy.)
In the policy file they add the following:
keystore "<URL of keystore file>";
grant signedBy "<certificate alias>" {
permission java.security.AllPermission;
};
This is a tedious solution that requires customer work on every machine that might use our WebStart application. But at least it doesn't require a new version of the application. It's still secure since we sign all our jars.
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1470818 is a reply to message #1470728] |
Wed, 12 November 2014 17:03   |
Eclipse User |
|
|
|
In our situation, we modified the .jnlp (changed main-class) to call into the wrapper class that we created instead of calling into org.eclipse.equinox.launcher.*. That is pretty much all you should need to do. You may also need to change the <jar href under resources (or include another entry) to point to the plugin that contains the wrapper class you created. I'm sure there are other ways of doing it but this is how we did it.
|
|
|
|
Re: WebStart Java 7 update 71 72 [message #1470965 is a reply to message #1470859] |
Wed, 12 November 2014 19:32   |
Eclipse User |
|
|
|
You don't necessarily have to create a new plugin. If you already have a plugin that you manage as part of your application then you can add the class to that plugin and reference it from the .jnlp.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1472996 is a reply to message #1454645] |
Fri, 14 November 2014 08:54   |
Eclipse User |
|
|
|
How did you know javaws in 7u72 forces use -Djava.security.manager?
Is it possbile to disable the security manager?
Now, with the workaournd, my web start app can be launched, but encounter performance issues: org.eclipse.ui.dialogs.FilteredTree reponse very slow. I guess it's caused by the security manager.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1473408 is a reply to message #1472996] |
Fri, 14 November 2014 15:59   |
Eclipse User |
|
|
|
You can see the command that JWS executes, to launch the application, in the trace logs . We compared the command that was executed in older versions of the JRE to the new versions. We saw that the new versions were adding:
-Djava.security.manager
I did not find a way to disable this.
|
|
|
Re: WebStart Java 7 update 71 72 [message #1476990 is a reply to message #1473408] |
Mon, 17 November 2014 14:25   |
Shaun Galey Messages: 16 Registered: July 2009 |
Junior Member |
|
|
Is it impossible to pass this as an argument to the launcher itself inside the jnlp?
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
<argument>-nosplash</argument>
<argument>-product</argument>
<argument>org.product</argument>
<argument>-data</argument>
<argument>@user.home/Application Data/product</argument>
<argument>-dev</argument>
<argument>@user.home/Application Data/product</argument>
</application-desc>
I used this method in previous java updates, will this not work in this instance?
Aren't we essentially doing this? We just want to pass in the argument for eclipse.security......or is it because this eclipse.security parameter isn't for the equinox launcher but for the jvm itself?
As a trial, I have added a wrapper class using code provided above to my main plugin that launches on the client side through the jnlp. The issue with that is I don't have (org.eclipse.equinox) as a jar on that plugin build classpath. This prevents me from building the client plugin. Equinox is called from the jnlp but not built with the plugin. If I place equinox on the classpath of the plugin through a lib add, won't that affect the classpath of the jnlp launch?
[Updated on: Mon, 17 November 2014 14:53] Report message to a moderator
|
|
|
Re: WebStart Java 7 update 71 72 [message #1477187 is a reply to message #1476990] |
Mon, 17 November 2014 17:53   |
Eclipse User |
|
|
|
Shaun,
First you should not pass the property as a JVM argument. It should be passed via a runtime property using the <property> tag. The issue is that if your jnlp is not signed properly JWS will only allow properties that it thinks are "secure". In our case these are properties that start with "jnlp".
In order to work around the property security you need to prefix the property with the string "jnlp" like so:
<property name="jnlp.eclipse.security" value="osgi" />
Now you will create a wrapper application that is a simple java class with a main that strips out the "jnlp." strings from all current runtime properties and then manually launches the Eclipse Framework with the striped runtime properties. There is an example of this class and its relative launch.jnlp change above.
https://www.eclipse.org/forums/index.php?t=msg&th=831402&goto=1446228&#msg_1446228
|
|
|
Re: WebStart Java 7 update 71 72 [message #1504562 is a reply to message #1445462] |
Tue, 09 December 2014 11:07   |
Eclipse User |
|
|
|
Thanks you so much everybody !
I've been strugglingwith this for 2 days with no results ...
<property name="jnlp.osgi.parentClassloader" value="current"/>
This added to the jnlp made my application work against java 7u71 !!!
|
|
|
|