使用 Java 7 Update 45，不再从 JNLP 标记“属性”设置系统属性
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19400725/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
With Java 7 Update 45, the System Properties no Longer Set from JNLP Tag "Property"
提问by user2885888
We run the application from the attached JNLP. On the Java console, we have output the system properties with D. The properties from our JNLP files are not set any more. This is the first Java version that we get this sort of problems with. Everything was working fine up to and including 7 Update 40.
我们从附加的 JNLP 运行应用程序。在 Java 控制台上，我们使用 D 输出系统属性。不再设置 JNLP 文件中的属性。这是我们遇到此类问题的第一个 Java 版本。一切正常，直到并包括 7 Update 40。
We have all the jars signed but there are no security attributes in their manifests.
我们已经对所有 jar 进行了签名，但它们的清单中没有安全属性。
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://10.0.10.230/webstart/app" href="desktop.jnlp">
<information>
<title>MyApp Desktop</title>
<vendor>MyApp GmbH</vendor>
<homepage href="http://www.myres-edv.de"/>
<description>MyApp Desktop</description>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.5+" initial-heap-size="512M" max-heap-size="1024M" javaws-vm-args="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8200"/>
<property name="org.omg.CORBA.ORBInitialHost" value="10.0.10.230"/>
<property name="org.omg.CORBA.ORBServerHost" value="10.0.10.230" />
<property name="sun.net.spi.nameservice.provider.1" value="dns,sun" />
<property name="MyApp.baktswritedos" value="true"/>
<property name="MyApp.nocomm" value="true"/>
<property name="MyApp.la.erfassungdos" value="true"/>
<property name="com.sun.corba.ee.transport.ORBTCPConnectTimeouts" value="500:30000:40:30000" />
<property name="deployment.trace.level" value="all" />
<jar href="myresjar/ejb/myres/myres_ejb_client.jar" main="true" download="eager"/>
<jar href="myresjar/ejb/myres/myres_ejb.jar" download="eager"/>
<extension name="jars" href="commonejbjars.jnlp"/>
<extension name="jars" href="jr.jnlp"/>
<extension name="jars" href="commonjars.jnlp"/>
<extension name="jars" href="commonjh.jnlp"/>
<nativelib href="myresjar/ejb/myres/myres_dll.jar"/>
</resources>
<resources os="Windows">
<nativelib href="myresjar/myres/native-dlls.jar" download="eager"/>
</resources>
<application-desc main-class="de.myapp.gui.desktop.mainframe.DesktopMainFrame">
<argument>-serverIP=10.0.0.230</argument>
<argument>-initNewDayAction=true</argument>
</application-desc>
</jnlp>
回答by user2886002
Had the same problem and solved it by signing the jnlp file. Your main jar should contain a copy of the jnlp file renamed as APPLICATION.JNLP and placed under JNLP-INF folder.(the name of the folder and jnlp file must be uppercase)
有同样的问题并通过签署 jnlp 文件解决了它。您的主 jar 应包含重命名为 APPLICATION.JNLP 并放置在 JNLP-INF 文件夹下的 jnlp 文件的副本。（文件夹和 jnlp 文件的名称必须大写）
回答by Michael Paesold
We experienced the same Problem with Java 7 Update 45 (1.7.0_45). The JNLP Specgave a hint for a work-around:
我们在 Java 7 Update 45 (1.7.0_45) 中遇到了同样的问题。该JNLP规格给了一个变通的提示：
Properties set in the jnlp file will normally be set by Java Web Start after the VM is started but before the application is invoked. Some properties are considered "secure" properties and can be passed as -Dkey=value arguments on the java invocation command line.
The following properties, as well as properties beginning with either "javaws." or "jnlp.", are considered "secure" and will be passed to the VM in this way: ...
在 jnlp 文件中设置的属性通常在 VM 启动之后但在应用程序被调用之前由 Java Web Start 设置。某些属性被视为“安全”属性，可以在 java 调用命令行上作为 -Dkey=value 参数传递。
以下属性以及以“javaws”开头的属性。或“jnlp.”，被认为是“安全的”，并将以这种方式传递给 VM：...
While "insecure" properties stopped working, we realized that "secure" properties would still be set correctly. Maybe the mechanism that sets properties after the VM is started but before the application is invoked, got broken with this Java update, or maybe this was an intentional but undocumented change.
当“不安全”属性停止工作时，我们意识到“安全”属性仍然可以正确设置。也许在 VM 启动之后但在应用程序被调用之前设置属性的机制被 Java 更新破坏了，或者这是一个有意但未记录的更改。
The work-around now depends on the type of system properties:
现在的解决方法取决于系统属性的类型：
For system properties that affect Java behavior or libraries, we changed our code to call System.setProperty()at the application start instead of setting them in the JNLP.
对于影响 Java 行为或库的系统属性，我们将代码更改为在应用程序启动时调用System.setProperty()，而不是在 JNLP 中设置它们。
For properties that we use to configure the application from the JNLP file, we added the jnlp.prefix so that they are passed correctly again.
对于我们用来从 JNLP 文件配置应用程序的属性，我们添加了jnlp.xml文件。前缀，以便它们再次正确传递。
<property name="myconfig" value="DE" />
to
到
<property name="jnlp.myconfig" value="DE" />
Edit:According to OpenJDK Bug JDK-8023821, the change was intentional:
编辑：根据OpenJDK Bug JDK-8023821，更改是有意的：
Starting from 7u45 launch descriptor (JNLP file) need to be signed in order to set insecure system properties. So it is expected behaviour in 7u45... (from a comment)
从 7u45 开始，启动描述符（JNLP 文件）需要签名才能设置不安全的系统属性。所以这是 7u45 中的预期行为......（来自评论）
回答by Sergey Nebezb
I set as:
我设置为：
<jnlp>
...
<application-desc main-class="Main">
<argument>param1=value1</argument>
</application-desc>
</jnlp>
Ps. Just be aware that passing values using tag you are passing application parameters and not JVM parameter. Your application should catch this parameter in your method main(String args[])
附言。请注意，使用标记传递值是传递应用程序参数而不是 JVM 参数。您的应用程序应该在您的方法 main(String args[]) 中捕获此参数
回答by PRS
We got bit badly by this same issue. We ended up going the route of including the JNLP file in the signed jar, but that presented some tricky build issues for us, because we had previously built one set of JARS and used multiple JNLP files to support different environments (QA, Production, Demo, etc), passing the environment details through to the app via a system property. We did try to make use of a JNLP template file as discussed here, http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/signedJNLP.html, but we kept getting errors related to verifying the JNLP file and gave up due to time constraints. It's possible we were just doing something wrong, but the error messages did not make it at all clear what part of the JNLP file didn't match the template. Additionally, there is this somewhat unhelpful note in the link above that says: "Elements or attributes that may compromise security will be locked out from this feature." I could find no documented examples of such elements or attributes.
同样的问题让我们有点受不了。我们最终选择了将 JNLP 文件包含在签名的 jar 中，但这给我们带来了一些棘手的构建问题，因为我们之前构建了一组 JARS 并使用多个 JNLP 文件来支持不同的环境（QA、生产、演示）等），通过系统属性将环境详细信息传递给应用程序。我们确实尝试使用此处讨论的 JNLP 模板文件，http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/signedJNLP.html，但我们不断收到与验证 JNLP 文件相关的错误，并因时间限制而放弃。可能我们只是做错了什么，但错误消息根本没有说明 JNLP 文件的哪一部分与模板不匹配。此外，在上面的链接中还有一个有点无用的注释说：“可能危及安全的元素或属性将被锁定在此功能之外。” 我找不到此类元素或属性的文档示例。
回答by frasch333
Just spent 2 days trying to fix this problem, trying to sign jars and other files...and then I found the solution which seems to be very simple and is working fine:
刚刚花了 2 天的时间试图解决这个问题，尝试对 jars 和其他文件进行签名……然后我找到了似乎非常简单并且运行良好的解决方案：
I *put a jndi.properties-file with the following content in my JRE-home-director*y (jre7/lib):
我*在我的 JRE-home-director*y (jre7/lib) 中放置了一个 jndi.properties 文件，其中包含以下内容：
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=jnp://localhost:1099
I had this problem when updating from Java 1.6 to Java 1.7(51)...
从 Java 1.6 更新到 Java 1.7(51) 时我遇到了这个问题...
