I decided to dive in and try to deploy the server we developed at GiveCamp last week for the ‘Big Brothers and Big Sisters’ charity project. I started by mavenizing the project, so I had a war to deploy.

Then, I created a free Cloud Foundry account, installed their ‘vmc’ command line tool and ran the ‘vmc push’ command to deploy my way to the cloud. And it worked straight off! Don’t you just love it when tools just work?

Our webservice is now running on a remote server that can be accessed by the iPhone and Android apps the team is developing. We still have some database work to complete, but this feels like a nice step forward.

In the mean time, I am now officially a Cloud Foundry fan…

It was a really enjoyable weekend, and all for a good cause. Thanks to Walt Read and Iran Rodrigues for setting up and running it all so smoothly, and Dr Alex Liu from Fresno State for organizing the team…

fatal: The remote end hung up unexpectedly
ERROR: Hi sabram, it’s GitHub. We’re doing an SSH key audit.

Vague error but finally figured out that it is related to Github’s recent security compromise and that I needed to verify my SSH keys.

Couldn’t find much about the error on Google, so maybe this post will help someone else!

Life can be much broader, once you discover one simple fact, and that is that everything around you that you call life was made up by people that were no smarter than you. And you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you’ll never be the same again.

Complete source can be downloaded from here.

Simplest possible example

I am posting the simplest possible example I could get working. It is a grossly over-simplified example designed to focus purely on getting the Swing/Webstart/Maven combination working.
For example:

• The Swing client is the simplest possible Swing app you could possibly create (it just displays ‘Hello World’), since the focus is on the Swing/Webstart/Maven setup, not complex Swing coding
• There are very few dependencies on other projects, to keep the poms simple. Obviously real apps are likely to be much more complicated
• The example uses just 2 maven modules (client and web) when in reality, a real enterprise project would likely have many more (e.g. client, web, service, persist). The web module in this example could act as your entry point to those other modules.

Anyway, hopefully those simplifications keep the example easy to follow.

Basic overview

The example uses a simple 2 module (client and web) maven project, with the jnlp defined in the client module. You then need to build and deploy the artifacts (a zip containing the built jnlp bundle for the client module and a war for the web module) to a maven repository. The final piece of the puzzle is then downloading the client zip and web war to your app server of choice (e.g. tomcat).

Setup

Steps:

• 1. Setup maven folder structure




• 2. Create a simple Swing app




• 3. Create web.xml file




• 4. Create the template.vm file




• 5. Create our maven poms
• 5.1 Parent project pom




• 5.2 Create the client module’s pom




• 5.3 Create the webapp module’s pom

• 6. Build, deploy and run!

Note that the Maven project structure I am using here is (loosely) based on the maven multi module example from the maven docs. The dir structure is just the standard maven directory layout. We wont be using the test and resources folders for this simple example, but they are included as a placeholder.

1. Setup maven folder structure

I don’t know of a maven archetype for creating a multi-module project, so we need to do it manually. Create the following directory structure:

SwingWebstartMaven
-SwingWebstartMaven-Client
--src
---main
----java
----jnlp
----resources
---test
--SwingWebstartMaven-Webapp
---main
----java
----resources
----webapp
-----WEB-INF
---test

2. Create a simple Swing app

For our simple Swing app, we are using the simplest example possible – HelloWorld. This code needs to be placed in our client project, here

SwingWebstartMaven\SwingWebstartMaven-Client\src\main\java\com\shaunabram\swingwebstartmaven\HelloWorldSwing.java

package com.shaunabram.swingwebstartmaven;

import javax.swing.JFrame;
import javax.swing.JLabel;

public class HelloWorldSwing {
  public static void main(String[] args) {
    JFrame frame = new JFrame("HelloWorldSwing");
    final JLabel label = new JLabel("Hello World");
    frame.getContentPane().add(label);
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.pack();
    frame.setVisible(true);
  }
}

3. Create web.xml

Next, we create the simplest possible web.xml i.e. an empty one. For this example, we just need the webapp to serve our jnlp file (and associated jars). In a real application, the web module would be the interface your your server. For example, you might use Spring Remoting and HTTP invokers to allow your Swing client to communicate with a service layer via your web module.

JnlpDownladServlet

Note that our example does not use the JnlpDownloadServlet, purely to keep the example as simple as possible. You however, may want to configure our webapp’s web.xml to use the JnlpDownladServlet as it adds some extra benefits such as allowing you to use $$codebase instead of having to maintain hardcoded project URLs (e.g. the template.vm file in the next section would benefit from its use as it contains a hardcoded url). See some background info on the JnlpDownloadServlet here, and notes on how to configure your webapp to use JnlpDownloadServlet here.

Your web.xml should look something like below.
This file will be located here:

SwingWebstartMaven\SwingWebstartMaven-Webapp\src\main\webapp\WEB-INF\web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

</web-app>

4. Create the template.vm file

Next, create the template.vm file. This file is the template used to generate the jnlp file.
This file will be located here:

SwingWebstartMaven\SwingWebstartMaven-Webapp\src\main\jnlp\template.vm

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://localhost:8080/SwingWebstartMaven-Web/webstart" href="$outputFile">
 <information>
    <title>Swing Webstart Maven Project</title>
    <vendor>ShaunAbram</vendor>
 </information>
 <security>
 <all-permissions/>
 </security>
 <resources>
    <j2se version="1.5+" initial-heap-size="32m" max-heap-size="128m" />
    <property name="jnlp.versionEnabled" value="false"/>
    $dependencies
 </resources>
 <application-desc main-class="$mainClass">
 </application-desc>
</jnlp>

Note the use of the hardcoded URL for the codebase. You may need to change this for your local environment. For more options how the codebase is used, see here. Also, as noted above, utilising the JnlpDownloadServlet would allow use to remove the hardcoded URL and use $$codebase instead.

5. Create our maven poms

5.1 Parent project pom

Next, we define the pom for our parent project, SwingWebstartMaven.
This file will be located here:

SwingWebstartMaven\SwingWebstartMaven\pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.shaunabram.swingwebstartmaven</groupId>
    <artifactId>SwingWebstartMaven</artifactId>
    <packaging>pom</packaging>
    <version>1.0</version>
    <name>SwingWebstartMaven Project</name>

    <modules>
        <module>SwingWebstartMaven-Client</module>
        <module>SwingWebstartMaven-Web</module>
    </modules>

    <build>
        <pluginManagement>
            <plugins>

                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.5</source>
                        <target>1.5</target>
                    </configuration>
                </plugin>

            </plugins>
        </pluginManagement>
    </build>

</project>

5.2 Client module pom

Next, we define the pom for our client module.
This file will be located here:

SwingWebstartMaven\SwingWebstartMaven-Client\pom.xml

This pom is the most important part of this example as it is where we specify the details for the jnlp file generation. See here for JNLP File generation details.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>com.shaunabram.swingwebstartmaven</groupId>
        <artifactId>SwingWebstartMaven</artifactId>
        <version>1.0</version>
    </parent>
    <artifactId>SwingWebstartMaven-Client</artifactId>
    <packaging>jar</packaging>
    <name>SwingWebstartMaven Client</name>

    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo.webstart</groupId>
                <artifactId>webstart-maven-plugin</artifactId>
                <version>1.0-beta-2</version>

                <executions>
                    <execution>
                        <id>package</id>
                        <phase>package</phase>
                        <goals>
                            <goal>jnlp-inline</goal>
                        </goals>
                    </execution>
                </executions>

                <configuration>
                    <jnlp>
                        <outputFile>launch.jnlp</outputFile>
                        <mainClass>com.shaunabram.swingwebstartmaven.HelloWorldSwing</mainClass>
                    </jnlp>

                    <libPath>lib</libPath>

                    <sign>
                        <keystore>SwingWebstartMavenExample-KeyStore</keystore>
                        <keypass>YourPassword</keypass>
                        <storepass>YourPassword</storepass>
                        <alias>SwingWebstartMavenExample</alias>
                        <validity>3650</validity>

                        <dnameCn>Your Name</dnameCn>
                        <dnameOu>Organizational Unit</dnameOu>
                        <dnameO>Organization</dnameO>
                        <dnameL>City or Locality</dnameL>
                        <dnameSt>State or Province</dnameSt>
                        <dnameC>US</dnameC>

                        <verify>true</verify>
                        <keystoreConfig>
                            <delete>true</delete>
                            <gen>true</gen>
                        </keystoreConfig>
                    </sign>

                    <pack200>false</pack200>
                    <gzip>true</gzip>
                    <outputJarVersions>false</outputJarVersions>
                    <verbose>true</verbose>

                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

5.3 Webapp module pom

Next, we define the pom for our webapp module.
This file will be located here:

SwingWebstartMaven\SwingWebstartMaven-Webapp\pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>com.shaunabram.swingwebstartmaven</groupId>
        <artifactId>SwingWebstartMaven</artifactId>
        <version>1.0</version>
    </parent>

    <artifactId>SwingWebstartMaven-Web</artifactId>
    <packaging>war</packaging>
    <name>SwingWebstartMaven Web</name>

    <dependencies>

    </dependencies>

</project>

6. Build, deploy and run

Build

To build, simply do:

mvn clean install

Deploy

Deploying is a slightly trickier matter…

Web module

For the web module, you can simply build and ensure the generated war is placed in your tomcat webapps dir, by whichever mechanism suits you best.
For example,
1) Manually copy the war from the target dir to your tomcat dir (although if doing is manually like this, you may want to remove any version number i.e. it should be named SwingWebstartMaven-Webapp.war rather than SwingWebstartMaven-Webapp-1.0.war).
2) Add the following to the build/pluginManagement/plugins section of your parent pom (SwingWebstartMaven\SwingWebstartMaven\pom.xml)

                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>tomcat-maven-plugin</artifactId>
                    <configuration>
                        <url>http://localhost:8080/manager</url>
                        <username>your-tomcat-username</username>
                        <password>your-tomcat-password</password>
                    </configuration>
                </plugin>

And the simply do

mvn clean tomcat:redeploy

3) Write a script on your server than will pull the generated war from your maven repository (e.g. using wget to download from Nexus) and place it in your tomcat dir.

Client module

For the client module however, deploying it is a slightly trickier matter.
My preferred approach is to to utilise the script approach mentioned in step 3) above to also pull down the client zip (e.g. SwingWebstartMaven\SwingWebstartMaven-Client\target\SwingWebstartMaven-Client-1.0.zip), and extract the contents into the tomcat webapps dir (I like to put it in a webstart folder e.g. tomcat\webapps\SwingWebstartMaven-Web\webstart).
For example, the script could, among other things,

• Stop tomcat
• Determine the latest version of the project available in the maven repository
• Pull down the web module’s war tomcat/webapps
• Start tomcat (so the war will be extracted and deployed)
• Pull down the client module’s zip
• Unzip to (for example) tomcat/webapps/SwingWebstartMaven-Web/webstart

These are all just suggestions for deployment of course – how you do it is up to you. But my point is that I found extracting the client module’s generated zip file (containing the jnlp bundle) to be the easiest way to deploy a JNLP project to an app server to make it easily accessible for users.

Run

Whatever build and deployment method you choose, you should now be able to access your Webstart enabled Swing app from a URL like this:

http://localhost:8080/SwingWebstartMaven-Web/webstart/launch.jnlp

I did finally get everything up and running. You can skip ahead to my next post about the final working solution. Otherwise read below for the various options I experimented with before first, but either couldn’t get working or chose not to use.

Alternative approaches

1) Putting the jnlp details directly in the web module

I had the idea that putting the jnlp details directly in the web module so that when it came to generating the web module war, it would already contain the jnlp bundle, making deployment to the server easier. See my attempted solution here.
And I did get this solution working – for this simple example.

The issue I ran into was when I tried to extend the example to my real project which uses versioning (via the maven release plugin). As soon as I tried using version numbers other than 1.0 all round, I had issues, specifically with the jnlpFile/jarResources/version section. The web module suddenly had difficulty finding the client artifact in the maven repo. I suspect it was attempting to download the artifact before it had actually been deployed to the repository. I’m sure there is a way to make this solution work, but I couldn’t figure it out.

2) Bundling the jnlp files in a war using the dependency-maven-plugin

I tried following this example for the client, and this example for the web module which uses the dependency-maven-plugin with the objective of packaging up the JNLP bundle with the web’s module war to produce a single war that could be deployed to tomcat. See my attempt here.

The issue that I ran into was that the jnlp folder gets generated in the client target directory (e.g. SwingWebstartMaven\SwingWebstartMaven-Client\target in my example), but only the contents of the target/classes directory actually seemed to get copied to the web module. I tried working around this by modifying the client to generate the jnlp in classes directory e.g.

<jnlp><outputFile>../classes/launch.jnlp</outputFile></jnlp>

But then I seemed to run into issues with the webapp module being built before the client module.
Again, I’m sure there is a way to make this solution work, but I couldn’t figure it.

3) Use assembly plugin to combine client and web module outputs

I spent some time looking into this example which suggests creating a new module (which it calls webapp-bundle) whose sole purpose is to combine the output of the client and web modules by using using the maven-assembly-plugin. It aims to combine the web module’s war with the client module’s zip into a single deployable war.
I think this is probably a viable solution, but mid way through I decided it was just going to be easier to take the existing zip that is generated by the client module and unzip it to the application server (e.g. tomcat/webapps). That is basically what I did in my final solution. See my next posting for the details.

Some useful bookmarks

• JNLP goals overview
  Gives 2 pom examples, one using jnlp, jnlp-inline or jnlp-single goal and one using the jnlp-download-servlet goal
• JNLP Download Servlet example
  I omitted the from the example in my next posting, but I did end up using it in my real project. This link shows how to incorporate the JnlpDownloadServlet into your project. At time of writing the servlet wasn’t available in many nexus repos, so you will likely need to install in your local repo yourself.
• JNLP 101
  Some things that are not directly related to the Webstart Maven Plugin but can help you make good use of it.
• JNLP File Syntax
  Oracle page describing the JNLP file elements.

• JDK7 for MacOS X Developer Preview announced by Hasan Rizvi (SVP @ Oracle). Available here.
• Java FX to be open sourced, and it will be proposed to the JCP (Confirmed, see press release)
• JDK8 will be released in the summer of 2013 (not 2012 as previously discussed), as announced by Adam Messinger from Oracle

There was also mention of an Oracle Java Magazine, which I confess I had never heard of before.

For a summary of this morning’s announcements, see here.

Overall, not the most exciting keynote I have seen. It opened with a presentation from Juniper Networks. I didn’t find the topic of “Programming the network” to bring networks and apps closer together particular relevant for me personally. They then rolled out a bunch of other corporate folks from the likes of Intel, Redhat, IBM and ARM. The Twitter guy did announce that Twitter are joining OpenJDK as well as the JCP though.

On to the sessions…

Overall, I found this a really interesting talk. It was lacking in any sales pitch, nor did it have the unquestioning devotion to one particular framework that I felt some of the Java FX talks had. Instead it seemed like an unbiased look at web frameworks in general and a handful of frameworks in more detail, based on Richard’s extensive and hands on experience and SalesForce and Hyperic.

Richard started by listing some of the web frameworks that are out there today. He managed to list over 100 and there were still many missing (e.g. I couldn’t see Lift or Play listed).

Given the abundance of choices, I think it was wise to start with a broad definition of what a web framework is. His definition included something that uses MVP or MVC and provides an event model, resource management, data binding and that is ideally stateless.

He then talked about the evolution that has taken place from server side rendering to client side rendering (where you have a stateless server, with the component model living on the client side), and had a few interesting ‘Architecture Evolution’ diagrams in his slides.

Next, Richard talked about the consequences of ‘choosing poorly’, i.e. picking a framework not best suited to your project’s needs (steep learning curves, excessive boilerplate code, unable to debug templates etc). I got the feeling Richard had learned many of these the hard way. He followed with a set of criteria to help better define your web framework requirements and selection criteria to avoid such issues, including usage scenarios, environment (intranet, mobile) and team competencies. On a side note, he pointed out that using forms for posting had become old hat (and those ‘Are you sure you wish to resend’ popups are certainly annoying).

Then, on to the main event. Richard ran through 4 of the most popular web frameworks: Grails, Tapestry, Wicket and GWT. In each case he compared them using criteria such as AJAX support, friendly URLs, open source license etc. I won’t try to recreate his findings (again, see his slides), but I did come away with a higher opinion of both Tapestry (its Form builder using POJOs sounds particularly cool) and Wicket and I am definitely keen to learn more on GWT (which Salesforce.com use extensively).

In some of the follow up questions, Richard was asked about JSF, which he didn’t have very high opinion of (and he is not alone). I was however disappointed to not hear some info (merits or otherwise) on JavaFX, especially considering its high visibility at this year’s conference, but I also understand no one can know all frameworks.

Finally, he finished with an interesting thought – that one of the main scalability issues with any web framework is people i.e. the competencies and preferences of the developers on the team.

Find Richard’s slides here.

Some of the themes of this morning’s keynote talk were JavaFX 2.0, what will be coming in Java 8 and a new Oracle NoSQL Database. There are some links here, here and here (and I believe the videos will be posted soon here).

I just attended a very useful Java Web Framework comparison talk that I will try to post about shortly. I also met up with some of the DZone team. For now, I am going to some JavaFX talks.

If any of you are attending, let me know!