Evan Summers's Blog

Trip and Tick 2: JooJ up your project page with a Web Start demo

This series kicked off with Trip and Tick 1: Checking out a java.net project.

So you're hosting your project on java.net, and you've uploaded some screenshots. Supoib! The next step is putting a Webstart "Launch" button on your page, innit. Oh and a screencast video thingy, see the upcoming Trip and Tick 3: The Movie for that.

Since i'm too lazy to read the JNLP documentation, and to write a JNLP file from scratch by hand, i'm gonna use those firefox goggles for starters. Later we'll be forced to read Deploying Software with JNLP and Java Web Start and edit the JNLP XML by hand, when as expected, things don't work as expected right off the bat.

Using the goggles we quickly see that Netbeans has a JNLP tool, woohoo! And a tutorial aptly named Using Java Web Start in NetBeans IDE which i followed as follows.

We go to the Update Manager, choose the Netbeans Update Center Beta.

When in doubt press the OK button. Unfortunately the above screen does not have an OK button, so we try the Next button.

We add the Netbeans Module for Java Web Start.

I think we should meet and greet this module!

Now we see a Java Web Start item in the menu when we right click on our project. We enable this, and when we Run with Webstart, Netbeans generates our JNLP file, woohoo! It even provides a JNLP designer for for manipulating the file with the mouse, as you can see below. Oisome!

As expected from years of experience with softwarez, it doesn't work for us the first time, D'oh!

We enable the Java Webstart Console to see the exception, or just click on Details and select the Exception tab. We see it's a security permissions problem with the application trying to access system properties ie. command line options. Probably preferences would also cause a security violation. So i disable properties and preferences in the application.

Trying again, there is a different error, ie. progress, woohoo!

Looks like the above security exception is caused by field.setAccessible() ie. reflection.

Let's try a different angle of attack which is to disable sandbox security, for now. We do this by adding a security element with all-permissions into our JNLP as follows. If you know how to provide limited permissions, but not all permissions, eg. to allow reflection and "standard" stuff, but obviously not local file system access, please post a comment.

But we get a "jar not signed" JNLP exception, as we see when we click on Details and then the Exception tab.

For this to work we gotta sign the jar as detailed in Web Start Developer's Guide, which gives us the following keytool and jarsigner commands. (Update. Kirill Grouchnikov's "Signing jars for java.net Web Start applications" provides a great tutorial on signing your jars.)

    cd /opt/java5/bin
    keytool -genkey -keystore myKeystore -alias myself 
    keytool -selfcert -alias myself -keystore myKeystore 
    keytool -list -keystore myKeystore 
    jarsigner -keystore myKeystore /aptframework/netbeans/dist/aptframework.jar myself
    javaws /aptframework/netbeans/aptframework.jnlp

where the keytool commmands we do once only, to create our "keystore," and the jarsigner command we do to prep the jar prior to trying to web start it.

Now we write a JNLP file for our web page, as follows.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://jroller.com/resources/e/evanx/">
  <information>
    <title>AptFramework Demo</title>
    <vendor>aptframework.dev.java.net</vendor>
    <icon href="default"/>
    <offline-allowed/>
  </information>  
  <security>
     <all-permissions/>
  </security>
  <resources>
    <j2se version="1.5+" />
    <jar href="aptframework.jar"/>
  </resources>
  <application-desc main-class="aptcomponent.common.ZViewContext"/>
</jnlp>    

For going online, all that changes is the codebase, which is now an http URL, rather than a local file.

I found that the weblogs.java.net webserver transforms XML files somehow, like our JNLP file, so that Firefox displays the XML rather than launching Web Start. So we upload our JNLP file and our jar to jroller.com rather, because that seems to work.

Now we can insert the JNLP link into our HTML web page as follows.

<a href="http://jroller.com/resources/e/evanx/aptframework.jnlp">
   <img border=0 src="http://javadesktop.org/javanet_images/webstart.small.gif">
</a> 

Which looks like

(695k, unsandboxed, Java5)

which hopefully works for you!?

Addendum on Dependent Jar Resources

Kirill Grouchnikov's "Signing jars for java.net Web Start applications" addresses dependent jars, where these might be signed by someone else, eg. activation.jar  et al signed by Sun. In this case, you can't include these directly as jar resources in your JNLP. As Kirill shows, the trick is to wrap them in their own JNLP, and list that as the resource in your JNLP. I include such an example below, for completeness.

But if you have dependent jars that are signed by someone else eg. Sun, then you gonna get an error because your jars are not all signed by the same certificate, ie. yours. You can inspect the signing certificates et al, using the following command. (Incidently, the following JavaDB jar isn't signed, but for the sake of this discussion, let's pretend that it is signed by Sun.)

jarsigner -certs -verbose -verify /projects/aptframework/lib/derby.jar    

As Kirill shows, we can create a JNLP file for dependent jars which are signed by Sun et al, as follows.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="http://aptframework.dev.java.net" href="javadb.jnlp">
  <information>
    <title>JavaDB jar</title>
    <vendor>Signed by Sun Microsystems, Inc</vendor>
    <offline-allowed/>
  </information>  
  <resources>
      <jar href="derby.jar"/>
  </resources>
  <component-desc/>
</jnlp>    

where in this case, i'm gonna check-in dependent jars under the www subdirectory of my java.net project, in which case the codebase is my java.net project homepage.

And then in the resources section of our JNLP, we list dependent jars, including those wrapped in their own JNLP file, as follows.

  <resources>
    <j2se version="1.5+" />
    <jar href="aptframework.jar"/>
    <jar href="aptfoundation.jar"/>
    <extension href="javadb.jnlp"/>
  </resources>    

Now i've just gotta update my demo to actually use JavaDB, eg. for an in-memory database :)

Comments

• One additional thing you missed is mentioned in this blog entry. This presents a solution for having external jars signed by different certificates.

  Posted by: kirillcool on July 20, 2006 at 01:50 PM

• I really wish there was a way to specify what access it is you require, and give a reason for each requirement... Then the user could make an informed decision if they want to allow the application to run, rather than just blindly clicking "Yes" (or more likely "No").

  Posted by: timyates on July 21, 2006 at 02:19 AM

• 
  Tim, I'm with you on that. The various sandbox security settings should be checkable, eg. file system access, network access, reflection, preferences, et al, maybe via JMX on the SecurityManager (neither of which i know much about, so i could be talking nonsense).

  Then you could configure your javaws default settings as to which level of (in)security you wish to endure, eg. no local filesystem or network access. And/or javaws can list requested (in)security of webstart apps, so at least you can make an informed decision to continue or not.

  Kirill, thanks for that link - i wish i had found it before, to include in the above article! I will highlight it with an "update" at the end of the article :) Update. I did this but it's only on the link from my blog and not on the link from the frontpage, which is a pity - the permalink seems to change when you edit the entry, and the frontpage link stays out of date, and new comments, like this one, aren't reflected on it either :(

  After reading your blog entry, it ocurrs to me now that my tips above won't help most people, because most apps have dependencies on other jars, and as you show, you need to use the trick of wrapping dependent jars in their own JNLP, where those are already signed by someone else, eg. Sun.

  I looking forward to putting together a webstart demo with embedded JavaDB (using in-memory database), which i'll probably do when the next netbeans version with bundled JavaDB comes out. And then i'll at least i'll have a dependent jar :)
  

  Posted by: evanx on July 21, 2006 at 03:37 AM

• Thanks to kirillcool for his blog which helped me to get webstart up for my project http://exalto.dev.java.net which is not saying that this blog isn't useful. Netbeans users would definitely love it.

  Posted by: ovisvana on July 21, 2006 at 03:53 AM

• I just had a search in the Bug Parade for an RFE to do "informed security", but can't spot one... As there seems to be at least 3 of us (including bjb in Kirill's linked blog entry) who would like this adding, I am guessing I am missing it (due to my being rubbish at handling the bugparade searches)... Anyone else spot one? Anyone know if this is being worked on?

  Posted by: timyates on July 21, 2006 at 04:43 AM

• Requiring "all-permission" to launch a regular app... is not very security oriented IMHO.

  I do hope the "declarative permission" mechanism will be implemented in next webstart. This means, that you have to say exactly which permission you need in detail. The webstart "sand box" will then only grant you those ones. This is usefull for the webstart client to analyse the permission requirements of an application before it starts. So, user can be presented an advise based on rules : something like a synthetic "threat-o-meter" ;-)

  Posted by: bjb on July 24, 2006 at 12:45 AM

This work is licensed under a Creative Commons License.