What's with the new JNLP Missing items warnings in Java 7?

Question

My JNLP still works fine after our switch from Java 6 to Java 7, but it now throws a whole series of errors like this:

Missing Application-Name: manifest attribute for: http://blah.com/app.jar
Missing Permissions manifest attribute for: http://blah.com/app.jar
Missing Codebase manifest attribute for: http://blah.com/app.jar

It repeats several times for our main jar and a couple times for one of our library jars. However, it does not occur at all for the bulk of our library jars. JaNeLa lists some optimization opportunities (by changing some defaults), but none of those appear to be related, and no actual errors are found.

So far searching the web has left me empty handed on how to make the JNLP file format into something that Java 7 finds worthy. :-)

Jefferey

Answer 1

See Missing Codebase manifest attribute for:xxx.jar for an explanation for Permissions and Codebase. If you use ant, you can use the following to add the entries to the manifest:

<manifest file="${source}/META-INF/MANIFEST.MF" mode="update">
  <attribute name="Permissions" value="all-permissions"/>
  <attribute name="Codebase" value="${jnlp.codebase}"/>
  <attribute name="Application-Name" value="${app.name}"/>
</manifest>

Java 7 update 45 broke my Web Start SWT application might also have some interesting information

Manducate

Ahhh, in my case it's due to using Netbeans. I also misunderstood what it was asking. I've been twiddling the JNLP permissions attribute and nothing ever changes. :-) So, I guess I have the choices of twiddling my build.xml (which seems risky given the particular environment I'm in) or waiting and hoping Netbeans 7.3.2 comes out and adds this support. – Jefferey

Netbeans 7.4 has since come out. Unfortunately, builds that it makes are completely unusable as they result in NumberFormatExceptions inside "DeployManifestChecker.verifyCodebase". :-( – Jefferey

Some defaults changed in Netbeans 7.4. I was able to get around the wacky codebase error by switching it the generic codebase mode. However, the manifest errors continue. – Jefferey

Now I'm custom injecting the required manifest entries via "jar ufm" (and code signing script) that I have to run manually after letting Netbeans do it's thing. I hope the next version of Netbeans fixes 7.4's problems with manifests and certain certificate types. – Jefferey

Update: Netbeans 8 doesn't completely fix this issue yet. Maybe 8.1... Until then I'm using a custom, post build, script to jam the manifest entries into the .jar. – Jefferey

Answer 2

This issue affects both JNLP and applets. The jar files are required to have a permission attribute in the manifest file. I believe the other errors are less critical. The latest JRE shows end users a warning message stating that starting January, 2014 the latest JRE will refuse to run any applet or JNLP jar files with a missing Permissions attribute.

See Java SE7 technotes on manifest.

The Java tutorial has a section on modifying the manifest file but doing this with ant as suggested by @mth sounds simpler.

Sakhuja

Answer 3

I could make a self signed java web start application work with a workaround. Even though I can see warnings in the console, I get no more warnings. All I needed was:

1. adding the "Permissions: all-permissions" attribute in the manifest.

2. Adding the following tag in the jnlp file:

   <security>
      <all-permissions/>
   </security>
   

3. signing my jars with my own keystore

4. importing my own certificate in the Java Control Panel (on Windows).

Saddlecloth

Good info for testing, so I'll upvote. Won't help my particular case though as importing my own certificate into every client each time the app changes is not feasible. – Jefferey

In the firm I work hat we have created our our certificate (that is guilty for 10 years...). then we keep modifying the app.. but the certificate is the same – Saddlecloth

Good point, I could modify our build script to re-use a long term certificate instead of our current procedure. Right now we create a fresh certificate, valid only for 6 months, on every build. – Jefferey

We run a jar signer script each time we build our application with jenkins. – Saddlecloth

Answer 4

If you are using maven this can be done by simply adding something like this in your plugin configuration:

       <updateManifestEntries>
         <Permissions>all-permissions</Permissions>
         <Codebase>*</Codebase>
       </updateManifestEntries>

Taken from the plugin site here

Mutualism