5

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

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Brian Knoblauch
  • 20,639
  • 15
  • 57
  • 92

4 Answers4

6

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

Community
  • 1
  • 1
mth
  • 677
  • 1
  • 7
  • 19
  • 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. – Brian Knoblauch Oct 18 '13 at 17:29
  • Netbeans 7.4 has since come out. Unfortunately, builds that it makes are completely unusable as they result in NumberFormatExceptions inside "DeployManifestChecker.verifyCodebase". :-( – Brian Knoblauch Oct 24 '13 at 14:04
  • 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. – Brian Knoblauch Oct 28 '13 at 19:05
  • 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. – Brian Knoblauch Feb 18 '14 at 21:56
  • 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. – Brian Knoblauch Jun 17 '14 at 13:07
6

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.

Thorn
  • 4,015
  • 4
  • 23
  • 42
1

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).
Laura Liparulo
  • 2,849
  • 26
  • 27
  • 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. – Brian Knoblauch Jan 08 '14 at 12:25
  • 1
    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 – Laura Liparulo Jan 08 '14 at 13:32
  • 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. – Brian Knoblauch Jan 08 '14 at 14:09
  • We run a jar signer script each time we build our application with jenkins. – Laura Liparulo Jan 08 '14 at 14:36
1

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

Chris Ritchie
  • 4,749
  • 2
  • 36
  • 33