I have created several Spring MVC projects for both work and play, and am attaching my own simple version of the HelloWorld example here, based on the Spring blog example.
Find my maven ready source here.
Like my previous JSP/Servlet example, I find these templates useful for getting prototypes up and running.

I still default to log4j, but it sounds like logback (as the new alternative to log4j), wrapped by SLF4J (as the new alternative to commons logging) is the way forward. Both are written by Ceki Gülcü (blog), the original log4j author.

One approach to doing this would be to have multiple, full tomcat installations. This article instead details how to install tomcat once (in CATALINA_HOME) but have multiple independent instances (by utilizing CATALINA_BASE). This is a more streamlined approach that makes creating multiple instances easier and also simplifies upgrades/rollbacks of tomcat.

Version info

I have tested with tomcat 6 and tomcat 7 and it seems to work well with both.
These notes relate to a windows install, but should be easily modified for *nix.

Steps

First, download and install tomcat to whatever directory you choose. We will refer to this directory as CATALINA_BASE.
Now, repeat the following steps for each instance of tomcat you want to setup.

1. Create a new folder which will be your tomcat instance. Note that this should preferably not be in CATALINA_HOME. We will refer to this tomcat instance folder as CATALINA_BASE.
2. Copy the conf directory from CATALINA_HOME to CATALINA_BASE. (I think, strictly speaking, just copying the server.xml would suffice, but no harm in copying the whole directory for now).
3. Isolate your tomcat instance
   Edit CATALINA_BASE\conf\server.xml file so that the following ports do not interfere with other Tomcat instances:
   • HTTP connector port (e.g. use 8080, 8081 …)
   • Shutdown port (e.g. use 8005, 8006…)
   • AJP port (e.g. use 8009, 8010…)

   Obviously if you have more than 4 instances, the shutdown and AJP ports will start to clash, so adapt accordingly (e.g. Shutdown = 9000, 9001; AJP = 9500, 9501 and HTTP continues with =8084, 8085…).

4. Create the following empty directories under CATALINA_BASE
   • logs
   • temp
   • work
   • webapps

   Tomcat will use the first 3 as part of its normal running. The webapps directory is where you will place your projects.

5. Optional: Set up the default page and tomcat manager
   Copy CATALINA_HOME\webapps\ROOT and CATALINA_HOME\webapps\manager to CATALINA_BASE\webapps.
   This step is optional but will allow you access the default page (useful for ensuring tomcat is running properly) as well as the Tomcat Manager page (useful for managing tomcat and your deployed applications).
6. Create startup and shutdown scripts
   Create a bin directory in CATALINA_BASE.
   In that bin directory, create a file called startup.bat like this:

       set CATALINA_BASE=C:\tomcats\tomcat-x
       set CATALINA_HOME=C:\tomcats\apache-tomcat-7.0.21
       C:\tomcats\apache-tomcat-7.0.21\bin\startup.bat

   And create a file called shutdown.bat like this:

       set CATALINA_BASE=C:\tomcats\tomcat-x
       set CATALINA_HOME=C:\tomcats\apache-tomcat-7.0.21
       C:\tomcats\apache-tomcat-7.0.21\bin\shutdown.bat

   Note that these are just basic scripts; you can obviously customize as you see fit. You can also optionally create a setenv.bat in the same bin directory to set any environment variables.

That’s it! From each instance directory, run CATALINA_BASE\bin\startup.bat and you will have multiple instances of tomcat up and running simultaneously.

Related links

• Use multiple CATALINA_BASE to setup tomcat 6 instances on windows
• Running multiple Tomcat instances on one server
• How to create multiple tomcat instances
• Tomcat Configuration Using CATALINA_BASE

Troubleshooting

If you are having problems, it can be useful to have tomcat run in the same window you start it in (rather than popping up a window with an error that immediately disappears!). To do this, modify the last line in CATALINA_HOME\bin\startup.bat by replacing the word start with the word run

Unit Testing

The benefits of unit testing code are many and include allowing us to find problems early, enable refactoring with confidence, and even provide a form of documentation for our code. Writing code with testing in mind (or, in the TDD world, to make already written tests pass) helps us to write code that is modular, with low coupling and high cohesion.

Unit testing is a way to verify that a unit of code works as we expect and want. In Java, that unit is often centered around a method. Sometimes a small part of one method (such as a particularly if block); sometimes several methods (for example, in the case of the public method under test calling one or more private methods). However, what a unit test should not do is test outside its own class boundary since this gets in to the realm of integration testing.

Using Mock Objects

Inevitably however, your class will rely on the behavior of other classes. So, the issue then becomes how to deal with those other classes. We somehow need to isolate, or control, their behavior in order to be able to focus on the unit under test. (We will either test that other code separately or, in the case of 3rd party libraries, assume that it works well already.)

The solution to isolating your unit under test from the other collaborating classes is to use mock objects in place of those collaborators. Mock objects allow us to focus on just the code under test by mocking the collaborator’s behavior. We specify expectations for how our code will interact (methods calls and return values), control those interactions and confirm that everything in our unit test code works as expected. Mock objects are, in essence, a way to test our code in isolation from the rest of our software world.

Fortunately, in the Java world, we have several mock object frameworks available, including JMock, Mockito and EasyMock. There are some interesting discussions on the relative merits of each here and here. This article focuses on the functionality of EasyMock.

EasyMock

EasyMock uses a record/playback paradigm for unit testing with mock objects. In record mode, you record what methods you expect to be called on your mock objects (and specify how you want your mock to respond). In playback mode, your mocks wait for those expected calls, playing back the canned responses you have specified. EasyMock will alert you to any unexpected behavior, such as missing calls and incorrect argument or return values and can also alert you to other behavior such as unexpected method calls.

These are the basic steps for using an EasyMock mock object:

1. Create a Mock Object




2. Record the expected behavior




3. Switch to replay state




4. Call the methods under test




5. Verify the mock was used as expected

1. Creating Mocks

Creating a mock is simple. Simply call createMock and pass in the class of the interface to be mocked, For example:

    MyInterface mock = org.easymock.EasyMock.createMock(MyInterface.class);

Or better yet, statically import the EasyMock static methods in you class import statements. For example:

    import static org.easymock.EasyMock.*;
    …
    MyInterface mock = createMock(MyInterface.class);

(Note that this static import approach applies to pretty much all of the EasyMock methods discussed in this article).

That’s it! Mock created. I have included some details on more customized mocks below, but in most cases, you can simply skip to the next step: specifying the expected behavior.

Mock creation specifics

Using createMock creates a mock object that has 2 notable characteristics:

1. Order checking is disabled by default. That is, you can specify the method call expectations (more later) in any order you wish – they do not need to match the actual order of the method invocations at test run time.
2. Calls to unexpected methods cause the test to fail

However, EasyMock provides two other approaches for creating mocks…

Strict/Nice mocks

Strict Mocks

A strict Mock Object has order checking enabled by default (and calls to unexpected methods still cause the test to fail).

    MyInterface mock = org.easymock.EasyMock.createStrictMock(MyInterface.class);

Since method order invocation is important under normal use, I often create my mocks as ‘strict’ by default.

Nice Mocks

Like a regular mock, order checking is disabled by default but ‘nice’ mocks will also allow calls to unexpected methods to pass unnoticed. Nice mocks also have another useful behavior: They will do their best to create a return value for unexpected method invocations. Specifically, they will return 0 (for methods with a numeric return type), false (for methods with a boolean return type) or null (for all other methods).

I find nice mocks particular use for testing legacy classes (or classes that were perhaps not created with unit testing in mind) that may interact with a large number of other classes which my current tests have no concern with.

Partial Mocks

EasyMock also provides the capability to mock specific methods of a class while not mocking (i.e. keeping the real behavior) of others. I have not personally used this functionality yet, but it is available via the createMockBuilder method, which returns a IMockBuilderinterface.

Mocking concrete classes

The final point on mock creation is that although EasyMock (and indeed the use of mock objects in general) is most often associated with mocks of interfaces, you can in fact also create mocks of concrete class also. You simply use

    org.easymock.classextension.EasyMock.createMock(...)

instead of the more conventional

    org.easymock.EasyMock.createMock(...);

e.g.

    ConcreteClass mock = org.easymock.classextension.EasyMock.createMock(ConcreteClass.class);

2. Record the expected behavior for your mock

After creating our mock object, we next need to tell EasyMock how we expect that mock to be used, that is, what methods we expect to be called on it.

2.1 Simplest case

In the simplest case where the expected method call has no return values (i.e. void) and accepts no arguments, you simply just call the method directly. For example:

    mock.expectedOperation() 

EasyMock still picks up & records the expectation.

Note that if you need to apply other expectations (such as expected Exceptions, or number of invocations as discussed later) to these simple cases, you can do so by invoking expectLastCall() followed by your expectations.

In addition to these simple calls however, EasyMock also provides the capabilities to specify return types and argument values, where required…

2.2 Specifying return values

If the call to expectedOperation returns a value, you must specify what EasyMock will return to your calling code. This can be done using the andReturn() method (a method provided by the return object of EasyMock.expect(), IExpectationSetters).

For example:

    EasyMock.expect(mock.expectedOperation()).andReturn(expectedReturnValue);

Where “expectedReturnValue” can be any object or primitive that matches expectedOperation’s return type.

Gotcha:

If the expected operation does indeed return a value, and you do not specify
e.g. EasyMock.expect(mock.expectedOperation());
You will get an error like:

    java.lang.IllegalStateException: missing behavior definition for the preceding method call expectedOperation()

Note that you can also get this error if you forget to call replay() before using a mock – more below.

Advanced return values

If you need more advanced return type creation, e.g. creating a value (or an Exception) at runtime, you can use andAnswer(IAnswer answer). See IAnswer for more details.

2.3 Specifying arg values

In the simplest approach, to specify an argument value, you just pass it with the expected method call, as in:

    mock.expectedOperation(argValue)

or

    EasyMock.expect(mock.expectedOperation(argValue)).andReturn(expectedReturnValue);

EasyMock simply compares the actual method arguments and the expected arguments by using equals().

Flexible Argument Matchers

It is also possible to have EasyMock adopt a more flexible approach to matching actual and expected arguments. For example, you may be happy to just have

• any Object passed
• A String starting with a certain value
• A number in a certain range

Easyock support these, and more, using argument matchers such as

• anyObject()
• startsWith(String prefix)
• eq(X value, X delta)

For example:

    expect(mock.expectedOpreation(EasyMock.anyInt()));

See the EasyMock class API for more details (or the EasyMock readme).

2.4 Specifying how many calls are expected

EasyMock also provides the capability to either relax or tighten the rules regarding the number of calls expected for a method.

Specifying an exact number of calls

To specify that a method must be called a certain number of times, we can just repeat the expected call the required number of time, e.g.

    EasyMock.expect(mock.expectedOperation()).andReturn(expectedReturnValue);
    EasyMock.expect(mock.expectedOperation()).andReturn(expectedReturnValue);

But this can get tedious for large numbers of calls, so we can also do:

EasyMock.expect(mock.expectedOperation()).times(2).andReturn(expectedReturnValue);

Specifying an inexact number of calls

There are a number of other methods (again, all provided by the return object of EasyMock.expect()) allowing us to specify looser rules on the number of expected method calls. These are:

• anyTimes()
• atLeastOnce()

3. Switch to replay state

Switching a mock object to replay state is simply done by calling EasyMock.replay(), passing in the mock object.
e.g.

    EasyMock.replay(mock).

This should be done for all mocks you have created (or, alternatively, call EasyMock.replayAll())
If you forget to call replay() before using a mock you will get this error:

    java.lang.IllegalStateException: missing behavior definition for the preceding method call expectedOperation()

Calling replay tells EasyMock that you are no longer specifying expected method calls and moving into replay mode.

4. Call the methods under test

This part is not really EasyMock specific since this is the crux of your test and needs to be done even if you are not using mock objects.
e.g. if you are unit testing a method of a Service object, at some point you are going to have to call that method in order to test its effect.

5. Verify the mock was used as expected

The final step is where we ask EasyMock to confirm that all our expectations were met. That is, we ask EasyMock to confirm that a method call corresponding to each expectation we set is actually made. This can be done as either

EasyMock.verify(mock)

or

EasyMock.verifyAll()

Note that this step is not mandatory, but if it is omitted, there will be no verification performed that the expected behavior we specified actually took place. So for example, if you specify

    mock.expectedOperation() 

and expectedOperation is never called, the tests will still pass.

If verify() is called, exactly what checks are performed depends on the type of mock object we created in step 1.

Note that I personally find the exact behavior of verify to be one more confusing parts of EasyMock. The following is my understanding of it and you should consult the EasyMock documentation (and run some tests yourself) before relying on it!

• EasyMock.createNiceMock() – As discussed earlier, unexpected method calls are not flagged. Calling verify() on a nice mock simply checks that all your expected methods were called, in any order.
• EasyMock.createMock() – On a ‘normal’ mock, unexpected method calls will be be flagged (they would result in AssertionError: Unexpected method call) even without the call to verify. I think that the call to verify acts the same way as for a ‘nice’ mock’. That is, EasyMock simply checks that all your expected methods were called, in any order.

  [If anyone out there knows of a difference in the effect of calling verify() between a nick mock and a normal mock, I would like to know!]

• EasyMock.createStrictMock() – Again, unexpected method calls will be flagged, and the order of the expected method calls is also checked but this time, the order of the expected methods is also checked.

Again, with the same disclaimer as before of this being my understanding only, I have tried to summarize the above behavior in the following table:

References

EasyMock Documentation
Easier testing with EasyMock

Links

EasyMock Facts and Fallacies

    String sql = "select a,b,c from tableA";
    assertThat(sql, hasNumberOfSubstrings(",", 2));

See the source code below. I have been reading up on OSS licenses recently and decided to release this using the same license as Hamcrest – the new BSD license.

I have also attached a jar which includes the associated unit tests, although you will need the hamcrest-unit-test project to compile, which can be downloaded as part of the hamcrest all-in-one jar.

package com.shaunabram.hamcrest;

import java.util.regex.Pattern;
import org.hamcrest.*;

/**
 * Matcher which tests if a string contains a specified number of substrings.
 *
 * @author sabram
 */
public class HasNumberOfSubstrings extends TypeSafeMatcher<String> {

    private final String substring;
    private final int count;

    public HasNumberOfSubstrings(String substring, int count) {
        this.substring = substring;
        this.count = count;
    }

    @Override
    protected boolean matchesSafely(String item) {
        Pattern p = Pattern.compile(substring);
        java.util.regex.Matcher m = p.matcher(item);
        int actualCount = 0;
        while (m.find()) {
            actualCount++;
        }
        if (actualCount == count) return true;
        else return false;
    }

    public void describeTo(Description description) {
        description.appendText("String containing ")
            .appendText(count + " occurences of ")
            .appendText(substring);

    }

    @Override
    public void describeMismatchSafely(String item, Description mismatchDescription) {
      mismatchDescription.appendValue(count)
                         .appendText(" occurence(s) of ")
                         .appendValue(substring)
                         .appendText(" in ")
                         .appendText(item);
    }

    @Factory
    public static Matcher<String> hasNumberOfSubstrings(String substring, int count) {
        return new HasNumberOfSubstrings(substring, count);
    }

}

    assertTrue(a.equalTo(b));

becomes

    assertThat(a, equalTo(b));

A small change in this example, but Hamcrest’s benefits are many, enabling you to write much more flexible tests that are easier to read and have more meaningful failure messages.

    Benefits of using Hamcrest
        Improved readability of tests
        Better failure messages
        Combine Matchers
        Custom Matchers
    Limitations
        Don’t use if JUnit will do
        Finding the right Matcher
    Setup
    Trouble Shooting
    Links

Benefits of using Hamcrest

Improved readability of tests

The following code, which utilizes the Hamcrest API, is easy to understand, even if you have no understanding of Hamcrest, or Java for that matter:

    assertThat(car, is(equalTo(ferrari));
    assertThat(cars, hasItems(ferarri, porsche));

Basically, Hamcrest provides a fluent API.

Better failure messages

This is one of the biggest advantages of using Hamcrest.
For example, if you run the following test, which makes use of JUnit’s assertTrue method:

    @Test
    public void testGreatThan_JUnit() {
        int minimumPrice = 0;
        int actualPrice = -1;
        //using org.junit.Assert.assertTrue
        assertTrue(actualPrice > minimumPrice);
    }

You get the following terse and uninformative error:

java.lang.AssertionError

However if you rewrite the test to use Hamcrest’s assertThat method with the greaterThan matcher, as follows:

    @Test
    public void testGreaterThan_Hamcrest() {
        int minimumPrice = 0;
        int actualPrice = -1;
        //using org.hamcrest.MatcherAssert.assertThat
        //and  org.hamcrest.Matchers.greaterThan
        assertThat(actualPrice, greaterThan(minimumPrice));
    }

You would get the following much more informative error message:

java.lang.AssertionError:
Expected: a value greater than <0>
but: <-1> was less than <0>

Basically, assertThat will tell you what was expected and what the value actually was where as assertTrue will only tell you that you got false where you expected true.
(You can of course put an explicit error message in the JUnit assertion yourself of course, as in:
assertTrue(“Expected a value greater than ” + minimumPrice, actualPrice > minimumPrice);
But Hamcrest is more descriptive and avoids the extra effort.)

Combinations of Matchers

Hamcrest allows you to use weird and wonderful combinations of Matchers. The obvious example is using not(), but other combinations can be achieved using Matchers such as both(), either(), or(), anyOf(), and many more.

Create your own Matchers

You can also create your own custom Matchers too, by implementing the Matcher interface. I wrote a blog post with an example of a custom matcher, but you can also find good examples here and here.


Finally, as a wrap up to the benefits of using Hamcrest, see the JUnit release notes which includes a description of using the Matcher mechanism.

Limitations

Don’t use if JUnit will do

If there is already a suitable JUnit method to use, there may not be any benefit to using a Hamcrest Matcher. Specifically, if you are just comparing primitive or String values, JUnit’s overloaded assertEquals methods should be adequate. For example, the follow two test approaches are both fairly easy to read and give the same message on test failure:

	@Test
    	public void testEquals_JUnit() {
	    int expectedPrice = 0;
	    int actualPrice = -1;
	    //using org.junit.Assert.assertEquals
	    assertEquals(expectedPrice, actualPrice);
	    //java.lang.AssertionError: expected:<0> but was:<-1>
	}

	@Test
	public void testEquals_Hamcrest() {
	    int expectedPrice = 0;
	    int actualPrice = -1;
	    //using org.hamcrest.MatcherAssert.assertThat
            //and org.hamcrest.Matchers.equalTo
	    assertThat(actualPrice, equalTo(expectedPrice));
	    //java.lang.AssertionError: Expected: <0> but: was <-1>
	}

However, for anything more complicated than primitive or String comparison, Hamcrest’s Matchers are likely to be much more useful.

Finding the right Matcher

One of the issues I have with Hamcrest is that the matchers are not all available in one place. It makes finding the correct matcher difficult and also means your IDE’s code assist, or import organizer, is not likely to be much help either. Most matchers are accessible via the Matchers class (although confusingly there is also the CoreMatchers class, which seems to be a subset – I never quite figured that one out…). But other matchers are located in other classes and packages.

Example 1
The very useful hasItem matcher is available in the aforementioned Matchers class:

    import static org.hamcrest.MatcherAssert.assertThat;
    import static org.hamcrest.Matchers.hasItem;

    public class HamcrestExamples {

        List<String> list = new ArrayList<String>();

	@Before
	public void setup() {
		list.add("itemA");
		list.add("itemB");
	}

	@Test
	public void test() {
		assertThat(list, hasItem("itemA"));
	}
}

But if you want to use the very similar hasItems matcher, you need to know (or trawl the javadocs to find out) it is in the IsCollectionContaining class.

    import static org.hamcrest.core.IsCollectionContaining.hasItems;
    ...
        @Test
	public void testHasItems() {
		assertThat(list, hasItems("itemA", "itemB"));
	}

Example 2
There is a useful containsString() method in the Matchers class that returns a Matcher to check is a String contains a sub-String, but if you want to check if a String contains several sub-Strings, in order, you need to know to look at the StringContainsInOrder class.

Notes:

• It looks like the above hasItems example will be remedied in 1.3 where hasItems will be made available via the Matchers class.
• There is a very similar testing library that seems to overcome this problem called Fluent Assertions module from FEST. FEST has all the matchers available via a single static import. (Also, see this interesting comparison with Hamcrest – I see no reason not to use both)

Setup

1. Download the Hamcrest jar(s) from http://code.google.com/p/hamcrest/downloads (using the all-in-one Jar is easiest)
   

   Note that JUnit does ship with some Hamcrest classes included. However, I prefer to use the Hamcrest jars directly because

   • JUnit only includes the core Hamcrest (hamcrest-core) API classes. A much larger library of Matcher implementations is available by also using the hamcrest-library jars. Personally, I simply use the hamcrest-all.jar, which includes all the available Hamcrest classes.
   • The package names in JUnit are different than those in Hamcrest e.g. org.hamcrest.MatcherAssert.assertThat versus org.junit.Assert.assertThat
     I prefer to keep things simply by always referring to the native org.hamcrest packages directly.

   If you do choose to use the Hamcrest jars directly, it is also advisable to use the junit-dep jars. These come without the Hamcrest classes included, avoiding any uncertainty about which Hamcrest classes you are actually using.

2. Add the Hamcrest jar(s) to your classpath or maven dependencies.
3. Statically import Hamcrest’s assertThat construct and the Hamcrest matchers:
   

   import static org.hamcrest.MatcherAssert.assertThat;
   import static org.hamcrest.Matchers.*;

4. Start using Hamrests’s assertThat in your unit tests, instead of JUnit’s assertTrue and assertEquals etc
   e.g. instead of

       assertEquals(expectedValue, actualValue);

   use

       assertThat(actualValue, equalTo(expectedValue));

Perhaps in future postings I will talk about how to use Hamcrest’s Matchers with Mock object frameworks such as EasyMock and JMock.

Trouble Shooting

Error:

java.lang.SecurityException: class “org.hamcrest.Matchers”‘s signer information does not match signer information of other classes in the same package

You simply need to make sure the Hamcrest jar comes before JUnit in your classpath. Alternatively, use junit-dep.

Error:

cannot find symbol method
assertThat(java.util.List<ExampleClass>,org.hamcrest.Matcher<java.lang.Iterable<java.lang.Object>>)

or

cannot find symbol method
assertThat(java.util.List<ExampleClass>,org.hamcrest.Matcher<java.lang.Iterable<? super
java.lang.Object>>)

This error can happen with any iterable (not just Lists, as in the above example) using hasItem or hasItems (and possibly other matchers too). It is a known issue with Hamcrest at the moment and is documented here, along with some fixes. I took the not-pretty-but-works option of declaring the Matcher in a local variable first
e.g.

    assertThat(list, hasItems(item1, item2));

becomes

    Matcher<java.lang.Iterable<ExampleClass>> matcher = hasItems(item1, item2);
    assertThat(list, matcher);

Like I said, not-pretty-but-works.

Links

• Hamcrest home page
• Hamcrest Tutorial
• Hamcrest API docs – At the time of writing, the Hamcrest API docs seem surprisingly hard to come by online and there is an ticket for this on the Hamcrest site. There also seems to be some issues when building the javadocs for yourself:
  In the mean time, I have taken the liberty of posting them on my site here:
  • Hamcrest 1.2 javadocs
  • Hamcrest 1.3 RC2 javadocs

• JUnit API docs
• Fluent Assertions module from FEST

Intro

WebSockets is a technology that enables bidirectional communication between web browsers and server side processes. It provides a persistent connection between client & Server, hence enabling ‘push’ abilities where you can push data/notification to browsers from the client. Other client communication options to compare it with would be Ajax
and Comet (basically Ajax with long polling).

Specifications

• WebSockets API – This focuses on the client side programming model.
• WebSockets protocol – Describes the client/server communication in more detail. More complicated and 51 pages long. The WebSockets protocol is still actively being changed.

Browser Support

• Google Chrome 4.0.249.0 and higher (v5 has WebSockets enabled by default)
• Safari 5.0
• FireFox 4.0 beta 1
• IE 9: TBD

There was a suggestion that Apple have decided to disable WebSockets in iOS4 but this is unconfirmed and the speaker suspects Apple will support WebSockets in the future.

Server side support

• Apache Server – not supported yet
• Py WebSocket – designed for use with Apache Server (actually implemented by Google Chromium team.)
• There is also a DJango solution: django-websocket
• Jetty WebSocket Server – Jetty has supported WebSockets since last September. This seems to be a good option.

However, note that there is no standard service side Java API. Each Java container has it’s own API. Therefore it will likely be difficult to write WebSockets for one app server and do a straight port to another app server.

Projects

Other Java Projects supporting WebSockets:

• GlassFish/Grizzly (see a DZone posting on it here)
• jWebSocket
• JBoss Netty (see patch here)
• Caucho Resin

Sean finished by showing the Google Quake demo (also reported here).

The conclusion of the talk was on how to gracefully handle browsers that don’t support WebSockets (e.g. IE8). The main option here seems to be “The Graceful WebSocket“. This resorts back to using AJAX long pulling if WebSockets isn’t supported in the browser.

My Thoughts

WebSockets looks like one of the most interesting technologies that fall under the HTML5 umbrella. If it gets wide browser support (e.g. IE9), and perhaps some standardization on the server side, it could really take off and even potentially over take Ajax. Definitely one to watch…

The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…

Selenium Overview

Chris started off with an overview of Selenium – a tool for automating tests for web based applications. He then introduced us to the Selenium IDE – a Firefox add-on that allows you to set up tests by recording clicks on a web page, or by manually entering commands. The tests can then be played back as part of your automated test suite.

Creating Selenium Tests

Chris showed us the process by both executing an existing test he had already setup, and by walking us through the creation of a new test, which loaded a page, waited for text to be present, clicked on a link, and confirmed that text was present. The test was a html file, but he showed how to export it as TestNG and JUnit tests (although both exports resulted in kind of ugly java code!)

Possible hiccups with Selenium

One of the things I thought Chris did well was, in addition to pointing out all the many great things about Selenium, he also pointed out some of the slight issues with Selenium that he has encountered during his time using it, such as

• Difficulties getting the initial Open page to work
• Issues with where the test files get saved
• Making sure you have the tests run slow to start with (to avoid timing/loading issues)
• The Selenium IDE may be difficult to get working with IE (Firefox is fine)

Selenium Components

The main Selenium section then finished up with a quick over of the various Selenium Components:

• Selenium IDE
• Selenese Commands
• Selenium RC (Remote Control)

Chris also had a section on the ‘same origin‘ JavaScript policy that Selenium manages to circumvent by using the Selenium RC Server. He managed to explain the issue in simple terms.

Other functional test alternatives

Chris discussed other functional test alternatives by comparing Canoo to Selenium (Canoo is also an automated web app testing framework).

Chris also mentionted Umangite, Chris Richardson’s open source testing framework that makes Selenium tests easier to write. I have used this before, and agree it is worth checking out…

Using Selenium with Build Tools

He then discussed using Maven with Selenium, including using Cargo (e.g. using the cargo maven2 plugin). Cargo is a set of APIs that assists in

• installing web containers, such as Tomcat, JBoss
• booting and shutting them down
• deploying web apps (.wars, .ears)

Chris finished the Selenium & build tools section with a quick run through of using Selenium with Ant.

Continuous Integration

The final section of the presentation was a talk on Continuous Integration (CI). Chris described CI as:

• A dedicated box (see my follow up question below!) that runs regular full builds (including tests) of your software
• Build triggers when any developer checks into SCM
• Team is notified of any issues

And talked about how Selenium can be used with Hudson – a very cool CI tool from Sun. This leads well into next month’s SF JUG talk!

Q&A

Q: Do you have any info on WebDriver merging with Selenium?
A: No, but sounds interesting!

Q: How closely do test writers work with marketing people?
A: Chris suggested checking out the easyb framework, a behavior driven development framework that allows you to write conditions in a very abstract level, using a DSL that marketers can use and understand. He also suggested looking at the fitnesse framework.

Q: I asked Chris via email after the talk what he meant by needing ‘dedicated’ box/server for Continuous Integration.
A: He clarified that by ‘dedicated’, he just meant that the build box should not be a box that you are doing development on, and that there isn’t anything wrong with having a mix of services on one machine. e.g. having a qa box that has the CI server and maybe hosts the bug tracking system as well…

In a future article I would like to discuss validation including the use of custom error messages.

Note that these notes relate to version 2.5.6 of Spring, the latest production code at time of writing, and depend heavily on the corresponding Spring reference docs.

Data Binding

Spring MVC allows the use of command objects (aka form backing objects, model attributes, domain model objects – basically the objects used to transport data between your view and your controller) using just about any type. However, the Servlet API deals with form parameters as Strings. Spring uses a technique called data binding to covert between the String representation and the real underlying type. This enables user input to be bound to the objects you use to process user input. In other words, the values entered by a user in a form can be used to set the property values on a chosen object.
As well as binding the values, Spring includes support for validation and binding result analysis.

The binding functionality is provided by Spring’s org.springframework.validation.DataBinder class.
And when converting a String to some arbitrary type, DataBinders make use of ProperEditors. PropertyEditors are not Spring specific, but rather part of the JavaBeans API.

Using PropertyEditors

Spring heavily uses the concept of PropertyEditors to effect the conversion between an Object and a String.
Spring has a number of built-in PropertyEditors to make life easy (for a complete list, see here).
If you are using a custom type that Spring is unable to convert to and from a String, you will likely receive a lovely error such as this:

org.springframework.web.bind.ServletRequestBindingException: Errors binding onto object ‘dependsOnExoticType’; nested exception is org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object ‘dependsOnExoticType’ on field ‘type’: rejected value [test]; codes [typeMismatch.dependsOnExoticType.type,typeMismatch.type,typeMismatch.example.ExoticType,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [dependsOnExoticType.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’: no matching editors or conversion strategy found]

The solution is to create your own custom editor.

Creating a custom property editor

A custom property editor should be of type java.beans.PropertyEditor. It tells Spring how to convert to a String and back again. As an example, see the ExoticTypeEditor in the Spring reference docs here.

The question is then how to register the custom editor.

Registering your custom editor

There are several ways to ensure you custom editor gets registered.

1) Put Editor in same package

The simplest way (by far!) is to put the Editor in the same package as the class it handles. This is because the standard JavaBeans infrastructure will automatically discover PropertyEditor classes (without you having to register them explicitly) if they are in the same package as the class they handle, and have the same name as that class, with’Editor’ appended;

However, if putting the Editor in the same package as the class it handlers is not possible (If for example, you are using a custom type from a 3rd party library and hence you don’t have access to the source code), try one of the other options below…

2) CustomEditorConfigurer

Another approach to registering a custom PropertyEditor is to use a special bean factory post-processor called CustomEditorConfigurer.
This is the approach used in the spring reference manual for the ‘ExoticType’ example. Again, see
section 5.4.2.1. Registering additional custom PropertyEditors, here.

The CustomEditorConfigurer is used to register the new PropertyEditor with the ApplicationContext, which will then be able to use it as needed.

Gotchas

i) Won’t work with BeanFactory – only ApplicationContext
The PropertyEditors defined in the ‘customEditorConfigurer’ bean will only be automatically used if you are using an ApplicationContext implementation (i.e. will not work for BeanFactory). This is discussed here.
ii) Only works for ApplicationContext created beans – not data binding beans such as form objects
This approach only works for beans created by the ApplicationContext. The PropertyEditors that are registered via CustomEditorConfigurer are NOT available for use in the data binding infrastructure (this is discussed here and here).
I think this should be made more clear in the spring framework ref docs (although, in fairness, it is covered in the CustomEditorConfigure javadocs).

So, if you are using Spring MVC and dealing with form submission, the next option may be better…

3) Explicitly register your editor in initBinder

So, a better approach, as far as form data binding is concerned, is to explicitly register your editor within initBinder() in the relevant Controller. e.g.

@Controller
@RequestMapping("/exoticView.htm")
public class TestController {

	//post and get handling methods etc...

	@InitBinder
	protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) {
		binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
	}

}

4) Use a WebBindingInitializer

If you find yourself using the above approach (registering your customer editor in initBinder) in many controllers, and you use a annotation based controller (Spring 2.5+), then you can use a WebBindingInitializer to register global property editors.

To do this, create a class that implements the WebBindingInitializer interface, for example

public class GlobalBindingInitializer implements WebBindingInitializer {

    public void initBinder(WebDataBinder binder, WebRequest request) {
        binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
    }

}

Then update your web application context file to contain:

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
    <property name="webBindingInitializer">
        <bean class="GlobalBindingInitializer"/>
    </property>
</bean>

I discovered this approach in a posting on StackOverflow about hidden features of Spring . It means you can register an editor once and use it anywhere. This is now my preferred way to register custom property editors.

5) Use PropertyEditorRegistrar

Another mechanism for registering property editors with the Spring container, and the final one in the Spring reference docs, is to create and use a PropertyEditorRegistrar. See section 5.4.2.1.1 here. The docs say that this is a good approach “when you need to use the same set of property editors in several different situations”. I have used this approach successfully in the past, but to be honest, I don’t quite see the benefits beyond the GlobalBindingInitializer approach above and it seems to require a few more steps. (I also saw some confusing debate on exactly what steps are mandatory here)

6) BeanInfo

There is also a BeanInfo mechanism mentioned in the Spring docs which I admit I have never tried – or fully understood.