With Java 7 Update 45, the System Properties no Longer Set from JNLP Tag "Property"

Question

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.

We have all the jars signed but there are no security attributes in their manifests.

<?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>    

Coldiron

Be sure to check the JNLP using JaNeLA. – Illyria

1) <nativelib href="myresjar/ejb/myres/myres_dll.jar"/>^M Huh? 2) "there are no security attributes in their manifests." Add them. – Illyria

Answer 1

We experienced the same Problem with Java 7 Update 45 (1.7.0_45). The JNLP Spec gave a hint for a work-around:

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: ...

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.

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.

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.

<property name="myconfig" value="DE" />

to

<property name="jnlp.myconfig" value="DE" />

Edit: According to OpenJDK Bug JDK-8023821, the change was intentional:

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)

Instructions for signing a JNLP.

Nath

Oddly the instructions for signing a JNLP are no longer available as part of the Java 7 technote guides but you can still find them on the Wayback Machine and similar content is also covered on the Oracle Java tutorial blog – Corkhill

Answer 2

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.

Lollop

The note about the JNLP template file is good. I will test this in our environment and report about success/failure. – Nath

For future readers: Property is one of the elements that is "locked out from this feature" - meaning that properties cannot be wildcarded in the JNLP template. You can wildcard arguments in the JNLP though, and set them as System Properties within the main method of your application. See #20430789 – Doglike

Answer 3

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)

Redd

Obviously this does not work for dynamic JNLP files (e.g. to provide single sign on ticket credentials to the applciation). The solution of Michael Paesold is the only one fully working. Either this change wasn't intentionally or Oracle wasn't fully aware of the effects this change would have. The main issue I've got is that this change wasn't announced. My company now has got plenty customers complaining that 'our application is broken' :( – Thigh

@Peter: I feel your pain, but I think the change was intentional. Maybe misguided, but intentional... Was in a similar situation where a product was passing dynamic variables as sys props in the JNLPs, including stuff like an OAuth token. Because of recent changes we changed our build to produce signed JNLPs and realized that indeed we couldn't pass these values anymore. HOWEVER, you can workaround it by passing arguments. You can't wildcard all arguments at once, but you can wildcard them separately. And pass in there whatever you want: session data, tokens needed for auth, etc... – Dizen

@haylem: That's what we did, too - changed our application to pass in arguments. But I don't think it was intentional, this change was announced for the security update 7u51 (to be released January 2014) and accidently slipped to this version... – Thigh

Answer 4

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[])

Quartet

Answer 5

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:

I *put a jndi.properties-file with the following content in my JRE-home-director*y (jre7/lib):

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)...

Ending