Webstart java 8 update 25 [message #1447050] |
Fri, 17 October 2014 18:11 |
|
I have an application running with web start and I've been having problems since the java version 1.7.45 or so when they increased the security, I had to manually modify the plugins from eclipse to add the new requirements and so on.
Everything was working fine until one client update to the latest version of java 1.8.0_25.
With this version of java a problem of permissions with osgi happens and I don't know what it might be happening, this is the stack trace form the java console:
!ENTRY org.eclipse.osgi 4 0 2014-10-17 11:15:47.181
!MESSAGE access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
!STACK 0
java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.reflect.AccessibleObject.setAccessible(Unknown Source)
at org.eclipse.osgi.framework.internal.core.Framework.setNLSFrameworkLog(Framework.java:272)
at org.eclipse.osgi.framework.internal.core.Framework.initialize(Framework.java:182)
at org.eclipse.osgi.framework.internal.core.Framework.<init>Framework.java:162)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:261)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
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:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.WebStartMain.basicRun(WebStartMain.java:79)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
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)
My application is coded using the 3.7.2 version of eclipse.
I really appreciate any help regarding about what might be happening or how to solve it.
|
|
|
|
Re: Webstart java 8 update 25 [message #1451457 is a reply to message #1451241] |
Thu, 23 October 2014 21:40 |
|
Hi,
So far I've changed the security levels in the JRE and try some other configuration but with no luck. I'm going to start changing my application to see if I can find a solution.
But I really haven't found anything regarding it, I hope I'll find some help somewhere.
|
|
|
|
|
|
Re: Webstart java 8 update 25 [message #1455623 is a reply to message #1454965] |
Wed, 29 October 2014 15:19 |
Steve Hruda Messages: 3 Registered: October 2014 |
Junior Member |
|
|
It's not enough to add the property to your JNLP. You have to ensure that the property will be added to your System properties WITHOUT the "jnlp." prefix.
see Dieter's message:
https://www.eclipse.org/forums/index.php/mv/msg/831402/1446228/#msg_1446228
He wrote a wrapper which adds all properties which beginns with the "jnlp." to his System properties.
Note:
He does that because of the fact, that one of the last Java security updates removed the possibilty to set System Properties directly from the JNLP.
RECOMMENDATION:
I would recommend to write a wrapper which sets the System property "eclipse.security" and DON'T use the "jnlp." workaround .... Because you re-open a "security hole" which was already closed by Oracle.
[Updated on: Wed, 29 October 2014 15:21] Report message to a moderator
|
|
|
Re: Webstart java 8 update 25 [message #1455791 is a reply to message #1454965] |
Wed, 29 October 2014 19:11 |
Chris Mising name Messages: 13 Registered: July 2010 |
Junior Member |
|
|
Hi,
Setting eclipse security did allow our application to start, but when we perform an operation that relies on reflection we get the below error message.
access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
I wonder if setting the eclipse security manager as OSGI, means it drops the "all-permissions" attributes we had in the plugin manifests?
Quote:
eclipse.security
specifies that a security policy and manager should be configured when the framework is launched. If the launcher is used (org.eclipse.equinox.launcher) and this property is set to any value then the launcher will configure a java.security.Policy that grants all permissions to the launcher and the framework. When the framework is launched it will use this property to determine the security manager to use. If set to osgi then the Equinox security manager is used. This security manager is required to fully support the OSGi Conditional Permission Admin specification. If the property is set to the empty string then java.lang.SecurityManager will be used; otherwise the property specifies a security manager class that should be used as the security manager.
Sadly we thought we'd nailed it, only to hit this second issue further down the line!
Setting the parameter
System.setProperty("eclipse.security", "osgi");
Actually breaks our application in all java versions, not that we've released it...
[Updated on: Wed, 29 October 2014 19:22] Report message to a moderator
|
|
|
|
Re: Webstart java 8 update 25 [message #1461783 is a reply to message #1456520] |
Tue, 04 November 2014 23:23 |
|
It worked fine the workaround of creating a wrapper and then adding the property "System.setProperty("eclipse.security", "osgi");" . I tested in the 7th and 8th version of java and it works fine, I don't care much about the previous versions because I've seen that the browsers are forcing to update java.
|
|
|
Powered by
FUDForum. Page generated in 0.04649 seconds