simplericity

Make your war file executable with the Jetty Console Maven plugin

A while back I made a little Maven plugin that takes a war file and makes it executable. With executable I mean that it embeds a Jetty servlet container. Running java -jar myapp.war will deploy your war with the embedded Jetty instance.

This provides a very convenient distribution method for Java web applications. It lets you distribute your application as a single artifact. Your users are no longer forced to install a big and ugly app server just to run your app.

But if they really want to, the war is still a war file that can be deployed the "normal" way in Tomcat, Glassfish, Weblogic, Websphere or any servlet compliant web server. (You tell me you actually use Websphere? Seriously!?).

With a single distribution in a single file, there's also less chance of your users getting confused about how to get your application running.

Jan Bartel of Jetty fame asked for a link describing this plugin and since I didn't really have any thing useful, here's a blog post:

An example: The Puffin Secrets Webapp

Meet the Puffin Secrets webapp. This very small, yet very useful web application let us listen in on the puffins while they chat about Jetty:

Since puffins are a bit shy, we need to click the button to see what they really think about Jetty:

To make this war file executable, we need to add a bit of plugin configuration to our Maven pom.xml:

<plugin>
    <groupId>org.simplericity.jettyconsole</groupId>
    <artifactId>jetty-console-maven-plugin</artifactId>
    <version>1.23</version>
    <executions>
        <execution>
            <goals>
                <goal>createconsole</goal>
            </goals>
        </execution>
    </executions>
</plugin>

After running mvn clean install, we should now have a target directory looking like this:

Notice the -jetty-console.war version of your war file. This war file is now runnable with java -jar (On a Mac it's actually double-clickable!). Running the war will start a little Swing console (unless run on a server):

The flies are there to remind you that you probably have bugs in your code. Still you might want to use a less generic background image. This can be done by adding the following configuration:


<plugin>
    <groupId>org.simplericity.jettyconsole</groupId>
    <artifactId>jetty-console-maven-plugin</artifactId>
    <version>1.23</version>
    <executions>
        <execution>
            <goals>
                <goal>createconsole</goal>
            </goals>
            <configuration>
                <backgroundImage>${basedir}/src/main/jettyconsole/puffin.jpg</backgroundImage>
            </configuration>
        </execution>
    </executions>
</plugin>

This gives us a much more puffin-relevant background:

The console is currently pretty simple. It allows the user to select a port and start the application. As a convenience the console will open a browser with the correct URL. This saves the user some seconds. (When demoing a product, seconds matter!)

Command line options

While the graphical console is nice for demoing an application or distributing it to testers, for installation on a server we need some command line interaction. You can see a list of available options by typing java -jar myapp.war --help

Usage: java org.simplericity.jettyconsole.JettyConsoleStarter [--option=value] [--option=value]

Options:
 --sslProxied        - Running behind an SSL proxy
 --port n            - Create an HTTP listener on port n (default 8080)
 --bindAddress addr  - Accept connections only on address addr (default: accept on any address)
 --forwarded         - Set reverse proxy handling using X-Forwarded-For headers
 --contextPath /path - Set context path (default: /)
 --headless          - Don't open graphical console, even if available
 --help              - Print this help message
 --tmpDir /path      - Temporary directory, default is /tmp

Plugins

The core of the Jetty console is intentionally kept as small as possible. Additional functionality can be included by adding plugins to your plugin configuration. You might want to add the log4j plugin:

<configuration>
    <backgroundImage>${basedir}/src/main/jettyconsole/puffin.jpg</backgroundImage>
    <additionalDependencies>
        <additionalDependency>
            <artifactId>jetty-console-log4j-plugin</artifactId>
        </additionalDependency>
    </additionalDependencies>
</configuration>

This should give you an extra option when running --help :

Usage: java org.simplericity.jettyconsole.JettyConsoleStarter [--option=value] [--option=value]

Options:
 --sslProxied        - Running behind an SSL proxy
 --port n            - Create an HTTP listener on port n (default 8080)
 --bindAddress addr  - Accept connections only on address addr (default: accept on any address)
 --forwarded         - Set reverse proxy handling using X-Forwarded-For headers
 --contextPath /path - Set context path (default: /)
 --headless          - Don't open graphical console, even if available
 --help              - Print this help message
 --tmpDir /path      - Temporary directory, default is /tmp
 --logConfig file    - Read log4j configuration from file

The other plugins currently available are:

ajp: Lets you configure an AJP connector in Jetty
requestlog: Allows you to log requests to an access log for traffic analysis
jsp: Adds JSP support to your application
jettyxml: Allows you to apply arbitrary Jetty XML configurations to your Server or WebAppContext
gzip: Compresses your HTML, CSS and Javascript for bandwidth savings

If the available plugins don't match your needs, it's quite easy to make your own and include it with in <additionalDependencies/>. <additionalDependencies/> can also be used to add normal Maven dependencies, such as a database driver referred to in jetty.xml

Maven repository configuration

Since this plugin is not (yet) in the Maven Central repository, you'll need to add a pluginRepository to your pom.xml:

<pluginRepositories>
    <pluginRepository>
        <id>kos</id>
        <url>http://opensource.kantega.no/nexus/content/groups/public/</url>
    </pluginRepository>
</pluginRepositories>

<repositories>
    <repository>
        <id>kos</id>
        <url>http://opensource.kantega.no/nexus/content/groups/public/</url>
    </repository>
</repositories>

The complete puffin example webapp is available in Subversion here:

http://simplericity.org/svn/simplericity/trunk/jetty-console-example/

Back from a fantastic Java Posse Roundup 2009

After a 30 hours, 5 flights travel, last night I finally made it home from the Java Posse Roundup in lovely Crested Butte, Colorado. After sleeping for 13 hours I'm now feeling quite good.

Although I suffered jet lag, got a cold and had altitude induced headaches and nosebleeds I must say this was an absolutely awesome conference experience.

Day Zero was the alternative languages day. I enjoyed learning about Scala and LINQ, but after lunch I used my two feet and joined the JavaFX dojo. During lunch break I discussed lightning talks with Tor and Joe and we ended up spending the rest of the day creating a lightning talk timer application. Sitting next to Tor trying to keep up with his JavaFX hacking was very fun. I learned more JavaFX in a couple of hours than I probably would on a week on my own.

Tuesday through friday we had open space discussions on a wide variety of Java and software related topics. We had three or four sessions at the same time, so I'm looking forward to hear the ones I missed on the Java Posse podcast. By wednesday I had unfortunately lost my voice due to a cold. This turns out to be a serious handicap on an open space conference. Although I wasn't able to contribute much in the discussion I still had a great experience and I learned a lot.

The evening lightning talks was a great success and we had no trouble filling the slots. The mix of Java and non-technical talks worked out really well. I initially thought five minutes would be too tight, but it allowed for more talks and people really had to stay focused to get their points through. My personal highlight would be James Ward's Flex UI demos and Andrew Harmel Law's talk about zombies.

Crested Butte was a very nice town for this kind of conference. Many of us rented houses around town which turned out to be a great way of getting to know people. Many people went downhill or snowmobiling, but because of my cold I decided cross country skiing would be enough of a challenge. So I had a couple of really nice skiing sessions, here's a picture from one of them with Dave Briccetti, Dianne Marsh, Dick Wall and Joel Neely:

Waiting for my connecting flight in Denver I just had to take this picture:

Seems like the guy is trying to replace the wiper blades of the plane by leaning out the window. Eventually he gave up and a few minutes later a guy with a lift came and finished the job.

Slf4j on Glassfish: When smart ideas collide

Have you ever noticed how two ideas can seem really smart one by one, but not all that great when combined?

I recently tried to install Nexus, the excellent Maven repository manager from Sonatype. (And by the way: Every organization using Maven needs a repository manager and Nexus is the best one out there!)

A secondary goal of the project I was working on was to get some exerience using Glassfish. But sadly, Nexus failed to deploy on Glassfish:

All I got was this error message in the admin console. A closer look in the Glassfish logs didn't reveal any stacktrace or relevant messages. Since my project was a pretty busy one, I soon gave up and found another way to run Nexus.

A couple of days ago however, I decided to find out what caused the StackOverflowError. I restarted Glassfish with debugging enabled and attached IntelliJ IDEA's debugger to it. After setting an exception breakpoint it was easy to see what was really happening under the hood.

I redeployed and got a stacktrace starting with this:

httpWorkerThread-4848-1@1033 daemon, priority=10, in group 'Grizzly', status: 'RUNNING'
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:491)
at java.lang.StringBuffer.append(StringBuffer.java:302)
at org.apache.log4j.helpers.ISO8601DateFormat.format(ISO8601DateFormat.java:132)
at java.text.DateFormat.format(DateFormat.java:314)
at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternParser.java:444)
at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:64)
at org.apache.log4j.PatternLayout.format(PatternLayout.java:503)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.slf4j.impl.Log4jLoggerAdapter.log(Log4jLoggerAdapter.java:597)
at org.slf4j.bridge.SLF4JBridgeHandler.callLocationAwareLogger(SLF4JBridgeHandler.java:169)
at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:242)
at java.util.logging.Logger.log(Logger.java:452)
at java.util.logging.Logger.doLog(Logger.java:474)
at java.util.logging.Logger.logp(Logger.java:590)
at com.sun.common.util.logging.LoggingOutputStream.flush(LoggingOutputStream.java:90)
at java.io.PrintStream.write(PrintStream.java:414)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implWrite(StreamEncoder.java:395)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:136)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:146)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:204)
at java.io.Writer.write(Writer.java:126)
at org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:47)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.slf4j.impl.Log4jLoggerAdapter.log(Log4jLoggerAdapter.java:597)
at org.slf4j.bridge.SLF4JBridgeHandler.callLocationAwareLogger(SLF4JBridgeHandler.java:169)
at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:242)
at java.util.logging.Logger.log(Logger.java:452)
at java.util.logging.Logger.doLog(Logger.java:474)
at java.util.logging.Logger.logp(Logger.java:590)
at com.sun.common.util.logging.LoggingOutputStream.flush(LoggingOutputStream.java:90)

and then about 1000 more lines of the same. There was clearly some kind of loop in the logging system that eventually caused the StackOverflowError. How could this happen?

I knew Nexus was using SLF4J, the Simple Logging Facade for Java. SLF4J was set up to log to Log4J. And Log4J was set up with a ConsoleAppender. From the stracktrace I could tell that Log4J wasn't printing its output to the console, but to a LoggingOutputStream. Some googling revealed that LoggingOutputStream is set up by Glassfish to catch any output to System.out and redirect it to the Java Logging API (JUL).

So Log4J was obviously feeding its log lines into what it thought was the console while it was actually fed into the Java Logging API instead. But why did this cause a loop?

The answer is found a few lines up the stacktrace in a class called SLF4JBridgeHandler. This class installs a bridge that will redirect all logs from the Java Logging API back to SLF4J. Which is pretty smart thing to do if you have code logging to JUL, but you want all code to log to be handled throgh SLF4J instead. Combined with Glassfish's LoggingOutputStream however, it caused an infinite loop:

The Nexus application code logs to SLF4J
SLF4J logs to Log4J
Log4J writes its log lines to System.out through the configured ConsoleAppender
The log lines are processed by Glassfish's LoggingOutputStream and sent to Java Logging
Java Logging sends its logs to SLF4J because of the SLF4JBridgeHandler.
SLF4J logs to.. Wait.. Houston, we have a problem!

So the next time you come up an idea you think is really smart, take a minute or two to consider the possibility that right now, somewhere else in the world, someone else might be thinking about an equally smart idea that when combined with yours will make the world explode.

This issue is reported in the Nexus issue tracker as NEXUS-1307.