simplericity - Java category

DogmaticMVC: The MVC framework that lets you know when you suck

Thu, 11 Nov 2010 21:22:00 GMT

Yeah, I know, I know.. Does the world really need Yet Another Web Framework?

Ok, perhaps not. But I had this idea, and I felt like implementing it. The result is a web framework that takes test driven development to the extreme.

DogmaticMVC was first presented in a lighting talk at the great Java Posse Roundup conference back in March. The noticeable amount of grinning among the audience encouraged me to submit a talk about it for XP2010. And now I'm presenting it at the Smidig 2010 agile conference in Oslo next week. So I figured it was about time I blogged about it.

Let's see what development with DogmaticMVC looks like. Here's a controller responding to the /HelloWorld URL:

Pretty simple code. (Groovy code actually.) If the client is in the local machine, we output the message "Hello Localhost". Otherwise, we output "Hello world". Accessing the application from localhost should produce "Hello Localhost". Right..? Think again:

DogmaticMVC has intercepted our request, looked at the code, found that it has no tests and refused to let us run it. After all, the the code has no tests, who knows what it will do?

So we add the @TestWith annotation and point it to our test class:

Admittedly not the world's most thorough test, but hey, it executes out code right? Let's see what DogmaticMVC has to say about the matter:

66% coverage? Sure we can do better. We'll add another test that will fake a request from localhost and thus execute line 11:

So now we have 100% line coverage. Very few projects out there in the Real World have that kind of test coverage. So are you happy now, DogmaticMVC? Let's save our test and hit reload:

This is DogmaticMVC letting us know (in polite terms) that even when they cover 100% of our code, our tests really suck. They suck because they don't assert anything about our code. In fact they just execute the code blindly and do not catch that DogmaticMVC mutated our code before running it, carefully injecting bugs by switching less than with greater than etc. Really, what's the use of tests if they don't catch bugs?

We can fix that by adding proper asserts that actually detect that code is not up to spec:

Now what?

This was actually cheating since I added a bug manually just to show that DogmaticMVC will detect it and show you the failing test. Once that "bug" is "fixed", we finally get what we wanted all along: Hello world. (Or as in this case, localhost)

Not only do we have a hello world that seems to work, we have a hello world that we can actually prove will work and that we can trust will continue to work.

As a bonus for reading this long, I present to you: A new feature! Web frameworks is all about features aren't they?

Speaking of features, let us for just a minute pretend that some real customer actually wanted our HelloWorld application. In fact, they like it so much they'd buy if it it only had this extra "near" feature. Sure we can add that? It's just a couple of extra lines of code. They clutter up our class, but the customer really wants it so we end up with this:

Now what does DogmaticMVC have to say about this code?

Here DogmaticMVC no longer sees any reason to stay polite. Feature creep is turning our code into a hairball. But this time we'll pick lazy honesty over hard work Software Craftsmanship and just slap the method with a @ThisMethodSucks annotation:

Are you in Oslo next week? Come see my talk at the Smidig conference, Wednesday 17th.

Make your war file executable with the Jetty Console Maven plugin

Tue, 10 Nov 2009 19:19:38 GMT

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

Tue, 10 Mar 2009 18:47:00 GMT

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.