Java web start issues when upgrading to j7u45

As you can guess from the title, the post will be devoted to the security update of Java, which will most likely break / launch the web start application. All not indifferent - I ask under cat.

Our company has adopted the practice of updating Java on all servers as soon as new versions are released. Actually, this is what we did this time. But something went wrong, the client’s web start client stopped running and the application, without a declaration of war, was simply shutting down.
Rolling up their sleeves, it was necessary to figure out what caused this behavior.

Having started the client locally, previously unknown warnings appeared that there are no properties in the manifest files: Permissions, Application-Name, Codebase. After reading a little about them, as a test, it was decided to add them to the fool in all manifestos, approximately in the following form:

Permissions: all-permissions Application-Name: AppName Codebase: * 

')
Not too beautiful, got rid of warnings, but did not solve the problem.
Further, during the long debugs (thank you Eclipse RCP for a happy childhood), it was noticed that the system parameters are transferred somehow wrong, which led to the next post on stackoverflow: stackoverflow.com/questions/19400725/with-java-update- 7-45-the-system-properties-no-more-set-from-jnlp-tag-property .
Summarizing it, we can say that now you can’t just take it and transfer it to the JNLP file.

3 solutions were found:
1) Sign the JNLP file - docs.oracle.com/javase/7/docs/technotes/guides/jweb/signedJNLP.html#signedJnlp - in short - just put jnlp in a signed jarik in the JNLP-INF folder with the name APPLICATION.JNLP and will be happiness.
The main problem with this method was that we have a different JNLP for each client and, generally speaking, it is generated on the fly.

2) Create a signed JNLP file template - blogs.oracle.com/thejavatutorials/entry/signing_jar_files_with_a
Initially, I settled on this method, nothing complicated: the same as in the previous paragraph, only the file name APPLICATION_TEMPLATE.JNLP and the places that can be changed are replaced by '*'.
But everything turned out to be not so rosy, nothing worked. I had a little bit to shaman and get into the inside of the web start, to see how the template and the jnlp file itself are compared. As a result, the following code was found in com.sun.javaws.jnl.XMLFormat:

  public static boolean isBlacklisted(XMLNode paramXMLNode) { if (paramXMLNode == null) { return false; } if (paramXMLNode.getName() != null) { XMLAttribute localXMLAttribute; String str; if ((paramXMLNode.getName().equals("java")) || (paramXMLNode.getName().equals("j2se"))) { for (localXMLAttribute = paramXMLNode.getAttributes(); localXMLAttribute != null; localXMLAttribute = localXMLAttribute.getNext()) { if (localXMLAttribute.getName().equals("java-vm-args")) { str = localXMLAttribute.getValue(); if ((str != null) && (str.indexOf("*") >= 0)) { Trace.println("Blacklisted - a = " + localXMLAttribute, TraceLevel.SECURITY); return true; } } } } else if (paramXMLNode.getName().equals("property")) { for (localXMLAttribute = paramXMLNode.getAttributes(); localXMLAttribute != null; localXMLAttribute = localXMLAttribute.getNext()) { str = localXMLAttribute.getValue(); if ((str != null) && (str.indexOf("*") >= 0)) { Trace.println("Blacklisted - a = " + localXMLAttribute, TraceLevel.SECURITY); return true; } } } } if (isBlacklisted(paramXMLNode.getNested())) { return true; } return isBlacklisted(paramXMLNode.getNext()); } 

It checks something like this: when comparing a template with a file, whether the current tag is in the black list, if not, it does not miss such a jnlp file. In the current implementation, you cannot add templates to the java-vm-args property of java or j2se tags, nor can you pass parameters that contain a pattern to the value.

And again, the failure, many properties for each client are unique and are passed just through the parameters in the form:

 <property name="client.specific.property" value="client.specific.value"/> 

And we can not just write in the template:

 <property name="client.specific.property" value="*"/> 

Only the last (at that time) option remains:

3) In accordance with bugs.openjdk.java.net/browse/JDK-8023821 , properties can be transferred by adding the prefix 'jnlp' to them, they will be successfully transferred to the system properties and then in our code it will be possible to shift them to their place . Since no other alternative was found, the code found here was added to the very beginning of the application launch:

  private static void initializeSystemProperiesFromJnlp() { //Hack for not signing JNLP file Properties properties = System.getProperties(); // copy properties to avoid ConcurrentModificationException Properties copiedProperties = new Properties(); copiedProperties.putAll(properties); Set<Object> keys = copiedProperties.keySet(); for (Object key : keys) { if (key instanceof String) { String keyString = (String) key; if (keyString.startsWith("jnlp.")) { //$NON-NLS-1$ // re set all properties starting with the jnlp-prefix // and set them without the prefix String property = System.getProperty(keyString); String replacedKeyString = keyString.replaceFirst("jnlp.", ""); //$NON-NLS-1$ //$NON-NLS-2$ System.setProperty(replacedKeyString, property); } } } } 

After this manipulation, everything worked.
Please note that the code given above is not a good tone rule, and at a minimum, it is worth checking the values ​​that are in the properties, suddenly they poked and replaced them.

In addition, there is another, more thorny, but the right way, which I learned about later. He is described here .

I hope this post will be useful to someone.