Shaun Abram

JavaOne: Tuesday’s Keynote

sabram — Tue, 04 Oct 2011 18:28:53 +0000

This morning’s Keynote at JavaOne contained a few interesting announcements, including

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…

JavaOne: Comparing Java Web Frameworks

sabram — Tue, 04 Oct 2011 05:07:06 +0000

The first talk I attended at this year’s JavaOne was “Choosing Your Java Web Framework” by Richard Pack from salesforce.com

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.

@JavaOne

sabram — Tue, 04 Oct 2011 00:26:57 +0000

I am at JavaOne 2011 right now. Always fun and it seems to be bigger than last year, with a huge selection of talks and presentations (although frustratingly flaky wifi!).

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!

Spring MVC Hello World

sabram — Tue, 20 Sep 2011 05:07:03 +0000

There is a good Getting Started with Spring MVC blog post over on the Spring team blog.

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.

SLF4J & Logback is the new commons-logging & log4j

sabram — Wed, 14 Sep 2011 05:04:51 +0000

Interesting post on which logging framework to choose from the logging mess.

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.

JSP EL statements not being evaluated

sabram — Sun, 11 Sep 2011 21:38:38 +0000

On several occasions I have had problems with EL (Expression Language) statements not being evaluated.
As an example, you add a statement to a JSP like
$(2+2), expecting the JSP to simply display 4, when it in fact displays the raw statement, i.e. $(2+2).

After digging around the web, I found a number of points to check…

Check you application server supports JSP 2.0 or above (Tomcat 5.0 and higher does)
Check your web.xml descriptor file is using at least version 2.4 of the Servlet deployment descriptor (I have been using 2.5). If it is using Servlet 2.3 spec or earlier, EL will be disabled by default.
Even if you are using version 2.5 of the Servlet deployment descriptor, make sure that the schemaLocation is correct. For example, I copied this from somewhere on the web and it failed to work:
I then found this version, which does work correctly. Note the subtle difference in the schema location of j2ee vs javaee.
```
           
```
I found the above here at Oracle.
As a last resort, you can use <%@ page isELIgnored="false" %> in your JSP, but having to do this is usually a sign that something else may be wrong (as described above).

XML Schema for the Servlet 2.5 deployment descriptor[java.sun.com]
Java EE 5 – Unified Expression Language[oracle.com]
JSP, JSTL, Servlet and Tomcat version matching[coderanch.com]
Stack Overflow related problem postings:

EL in a JSP stopped evaluating[stackoverflow.com]
JSP: EL expression is not evaluated[stackoverflow.com]
Javascript String.replace works weirdly in jsp file[stackoverflow.com]

Setting up multiple instances of Tomcat

admin — Thu, 08 Sep 2011 23:48:06 +0000

With multiple tomcat instances, each can run in its own JVM, have its own configuration and can be started/stopped independently. For example, you can have a dev, QA and Prod version of tomcat all running on the same box.

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.

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.
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).
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…).
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.
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).
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.

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

Add log4j logging for a unit test in IntelliJ

admin — Sat, 03 Sep 2011 18:36:30 +0000

In IntelliJ

Click: Run -> Edit Configuration
Select your test configuration (or add a new one)
In VM parameters, add
-Dlog4j.configuration=file:/C:/dev/config/log4j.xml
(Or wherever your log4j properties file is)

That’s it. The test should now run with log4j logging (although obviously you need to have the necessary log4j jars available).
This example uses a windows file format, but will work equally well with *nix.

I use this approach for turning on MyBatis logging for individual tests. See here for a basic setup of a log4j.xml file to enable logging with MyBatis.

EasyMock

admin — Wed, 17 Aug 2011 02:20:17 +0000

EasyMock is an open source library for creating, and defining the behavior of, mock objects as part of your unit tests. This article describes how to use EasyMock (v3.0), including its record/playback approach, after setting the context with an brief introduction to unit testing in general and the associated need for mock objects.

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:

Create a Mock Object

Record the expected behavior

Switch to replay state

Call the methods under test

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:

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.
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)

    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)

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:

	NiceMock without verify()	NiceMock with verify()	Mock without verify()	Mock with verify()	StrickMock without verify()	StrickMock with verify()
Checks for Expectations being met	N	Y	N	Y	N	Y
Checks for Expectations being met in exact order	N	N	N	N	N	Y
Unexpected methods flagged	N	N	Y	Y	Y	Y

References

EasyMock Documentation
Easier testing with EasyMock

Links

EasyMock Facts and Fallacies

Hamcrest Matcher

admin — Wed, 20 Apr 2011 05:50:08 +0000

As a follow up to the Hamcrest post I made yesterday, I wanted to post an example of my own Hamcrest matcher implementation. This matcher tests if a string contains a specified number of substrings.
An example usage could be:

    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 {

    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 hasNumberOfSubstrings(String substring, int count) {
        return new HasNumberOfSubstrings(substring, count);
    }

}

Shaun Abram

JavaOne: Tuesday’s Keynote

JavaOne: Comparing Java Web Frameworks

@JavaOne

Spring MVC Hello World

SLF4J & Logback is the new commons-logging & log4j

JSP EL statements not being evaluated

Setting up multiple instances of Tomcat

Version info

Steps

Related links

Troubleshooting

Add log4j logging for a unit test in IntelliJ

EasyMock

Unit Testing

Using Mock Objects

EasyMock

1. Creating Mocks

Mock creation specifics

Strict/Nice mocks

Strict Mocks

Nice Mocks

Partial Mocks

Mocking concrete classes

2. Record the expected behavior for your mock

2.1 Simplest case

2.2 Specifying return values

Gotcha:

Advanced return values

2.3 Specifying arg values

Flexible Argument Matchers

2.4 Specifying how many calls are expected

Specifying an exact number of calls

Specifying an inexact number of calls

3. Switch to replay state

4. Call the methods under test

5. Verify the mock was used as expected

References

Links

Hamcrest Matcher