The next step I took was to add a new integration test to verify when the server was shutdown all the clients were disconnected and stopped themselves.

We already had a client that we used for the test to send a message and then wait for the response.

So first of all we add a simple DisconnectLatch class:

package uk.co.bssd.netty.server;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

import uk.co.bssd.netty.DisconnectListener;

public class DisconnectLatch implements DisconnectListener {

	private static final long DEFAULT_TIMEOUT_MS = 1000;

	private final CountDownLatch latch;
	private final long timeoutMs;

	public DisconnectLatch() {
		this(DEFAULT_TIMEOUT_MS);
	}

	public DisconnectLatch(long timeoutMs) {
		this.latch = new CountDownLatch(1);
		this.timeoutMs = timeoutMs;
	}

	@Override
	public void onDisconnect() {
		this.latch.countDown();
	}

	public boolean awaitDisconnect() {
		try {
			this.latch.await(this.timeoutMs, TimeUnit.MILLISECONDS);
		} catch (InterruptedException e) {
			throw new IllegalStateException("Interrupted whilst awaiting on disconnect latch", e);
		}
		return this.latch.getCount() == 0;
	}
}

Then we amend the MessageCollectingClient to take an instance of this latch in the constructor. The client will call the onDisconnect method on the latch if it receives a disconnect event from the Netty framework.

We can then write a simple test like this:

	@Test
	public void testStoppingServerCausesDisconnectAtClient() {
		this.server.stop();
		assertThat(this.clientDisconnectLatch.awaitDisconnect(), is(true));
	}

The latch was constructed with the default timeout so will wait for 1 second before returning when we then check if it was successful.

Unfortunately the test didn’t pass first time, the client did not get a disconnect event. Upon investigation the server did not shutdown and release the resources nor close the connection.

The original implementation of the server stop method looked like:

	public void stop() {
		this.bootstrap.releaseExternalResources();
	}

This attempts to shutdown the threadpool executors used by Netty to manage both the connections and workers. The problem is because a client is connected there is a thread managing that connection and this call does not shut it down, it would only do so if the client disconnected or the channel was closed.

After a bit of digging and looking at some more examples I found the ChannelGroup interface. The Javadoc explains how it can be used to shutdown all the channels in a server in one go. Basically when a channel is created you ensure you add it to the group and then the stop method can call close on the group shutting down all the channels held within it. Another good thing about the group is that you don’t have to worry about Channels that have already been closed (such as if a client disconnects) as these get tidied up for you.

The stop method for the server now looks like:

	public void stop() {
		this.channelGroup.close();
		this.bootstrap.releaseExternalResources();
	}

It also means that the message handlers require a reference to the channel group and must add the channel to the group. To take care of this I created a handler which only concerns itself with channel life-cycle events:

package uk.co.bssd.netty;

import org.jboss.netty.channel.ChannelHandlerContext;
import org.jboss.netty.channel.ChannelStateEvent;
import org.jboss.netty.channel.SimpleChannelUpstreamHandler;
import org.jboss.netty.channel.group.ChannelGroup;

public class ChannelEventHandler extends SimpleChannelUpstreamHandler {

	private final ChannelGroup channelGroup;

	public ChannelEventHandler(ChannelGroup channelGroup) {
		this.channelGroup = channelGroup;
	}

	@Override
	public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e)
			throws Exception {
		this.channelGroup.add(e.getChannel());
	}
}

As long as the handler is registered with the channel pipeline (such as in the pipeline factory) then it will make sure all channels created get registered with the group. Now when the stop method is called on the server then it disconnects all the clients and the test passes.

This version of the code can be found on GitHub with this commit hash.

To this end I have setup a sandbox project on GitHub to play around with creating a very RPC style example in a similar vein to twitters Finagle. This isn’t about reinventing the wheel though, more about getting to understand the framework a bit better and I also intend to drive the development using an outside in testing approach in the GOOS style (see my previous post on the subject).

So far what I have committed is pretty much the same as the Object Echo example provided with Netty. The client sends a message (wrapped in an Object) to the server, which then unpacks the payload before wrapping it in a response Object and sending it back.

The main difference is that I have a single JUnit test which fires up a client and a server, sends a message and then waits for the response, the test looks like this:

package uk.co.bssd.netty.server;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

import uk.co.bssd.netty.client.MessageCollectingClient;
import uk.co.bssd.netty.dto.SimpleRequest;
import uk.co.bssd.netty.dto.SimpleResponse;

public class EchoServerIntegrationTest {

 private static final String HOST = "127.0.0.1";
 private static final int PORT = 6781;

 private static final long CLIENT_CONNECTION_TIMEOUT_MS = 1000;
 private static final long RECEIVE_MESSAGE_TIMEOUT_MS = 1000;

 private MessageCollectingClient client;
 private EchoServer server;

 @Before
 public void before() {
   this.server = new EchoServer();
   this.server.start(HOST, PORT);

   this.client = new MessageCollectingClient();
   this.client.start(HOST, PORT, CLIENT_CONNECTION_TIMEOUT_MS);
 }

 @After
 public void after() {
   this.client.stop();
   this.server.stop();
 }

 @Test
 public void testServerEchoesBackMessageSentFromClient() {
   String payload = "Hello";

   this.client.send(new SimpleRequest(payload));

   Object message = this.client.awaitMessage(RECEIVE_MESSAGE_TIMEOUT_MS);
   assertThat(message, is(SimpleResponse.class));

   SimpleResponse response = (SimpleResponse) message;
   assertThat(response.payload(), is(payload));
 }
}

Now that I have this very first test I intend to drive the development of the client and server by adding end to end tests one at a time and then working outside in adding smaller unit tests and getting them to pass by implementing the functionality. In the past I have tended to work very much inside out and am keen to see how this goes.

In the next part I plan to drive out what happens when a client disconnects from a server and vice-versa. The final part will then move on to being able to register messages handlers and ensuring the correct handler is invoked when the client sends a message.

In production we actually tend to use a JNDI lookup to get hold of our data source from a web container, which is generally a connection pool rather than a single connection as per the unit tests.

To illustrate the point a bit better I will walk through an example involving Spring Integration.

Spring Integration has the concept of message channels which is a mechanism to decouple message components. General a service would do some work produce a message output and then send that to a channel. On the end of the channel would be some form of adapter or gateway that would take the message and then route it on somewhere useful.

We have used channels with JMS quite a lot so we might have a JMS outbound adapter that takes a message from the channel and pops it onto a queue or topic ready to be picked up by the next thing.

So a very naive Spring Context file might look like:

<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration"
 xmlns:int-jms="http://www.springframework.org/schema/integration/jms"
 xsi:schemaLocation="
 http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
 http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration-2.1.xsd
 http://www.springframework.org/schema/integration/jms http://www.springframework.org/schema/integration/jms/spring-integration-jms-2.1.xsd">

 <bean id="myService" class="uk.co.bssd.example.MyService">
   <property name="dispatcher" ref="dispatcher" />
 </bean>

 <int:channel id="outbound" />

 <int:gateway id="dispatcher" service-interface="uk.co.bssd.example.Dispatcher"
   request-channel="outbound" />

 <int-jms:outbound-channel-adapter channel="outbound" destination-name="outbound-queue" />

</beans>

A brief explanation of what is going on here is:

1. The service has a dispatcher injected into it.
2. In this case the dispatcher is a proxied Spring Integration object that will take any method call and place the object passed to the method and place it on the outbound channel.
3. The JMS outbound adapter picks up the objects from the outbound channel and sends them to the to outbound-queue.

Now this is great and works fine, but it’s hard to test. If we want to test it then we need to either spin up a JMS queue and that’s quite involved considering all the service really cares about is that it dispatches the correct object.

So if we split our contexts into two, with context 1:

<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="
 http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

 <bean id="myService">
 <property name="dispatcher" ref="dispatcher" />
 </bean>

</beans>

Then context 2:

<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration"
 xmlns:int-jms="http://www.springframework.org/schema/integration/jms"
 xsi:schemaLocation="
 http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
 http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration-2.1.xsd
 http://www.springframework.org/schema/integration/jms http://www.springframework.org/schema/integration/jms/spring-integration-jms-2.1.xsd">

 <int:channel id="outbound" />

 <int:gateway id="dispatcher" service-interface="uk.co.bssd.example.Dispatcher"
 request-channel="outbound" />

 <int-jms:outbound-channel-adapter channel="outbound" destination-name="outbound-queue" />

</beans>

This gives us a bit more freedom for the unit test. Now we can write a context to stub out the dispatcher:

<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="
 http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd>

 <bean id="dispatcher"
 factory-method="createMock" primary="true">
 <constructor-arg value="uk.co.bssd.example.Dispatcher" />
 </bean>

</beans>

Now what this does is create an EasyMock version of the dispatcher bean.

So in our test we can simply put load context 1 and the test context together using the Spring JUnit test runner and the @ContextConfiguration and we can then @Autowired our mock dispatcher in and assert the correct object is dispatched to it.

To cut a long story short I think GOOS is excellent and is perhaps the best technical book I have read, better than the Pragmatic Programmer or Code Complete 2 in my eyes. I think the team have probably got fed up of me pushing the book at every opportunity!

Having said it’s a technical book it is not about a specific technology, yes the examples are in Java but they could apply to any Object Orientated language. The mocking framework of choice in the book is jMock but having used EasyMock before I have stuck with that but the ideas still apply, it’s more a question of personal preference and style.

The major strength of the book is that it flows like a story. The authors outline a realistic (or semi-realistic) application to build and then start at the beginning using the techniques they describe to push and pull the design of the evolving system as they go. They really show how to listen to the tests and how they get from the initial version to the next step.

A heavy emphasis is placed on mock objects, something I had used before but with mixed results. I was very familiar with the mess you can get yourself into with mocks where you end up with a load of tests that assert a method is called x times and when the implementation changes a huge swathe of tests fail. This is bad mocking and should be avoided at all costs. Having read the book and applying the principles I like to think that I don’t indulge in that kind of thing and use mocks appropriately.

Some of the things we have taken from the book and applied on a recent project to great success are:

1. Test Data Builders – we know use builders extensively throughout the system making it easy to build our objects and keep them immutable once built. Test Data Builders are then a great way to easily create test data without too much effort or repetition. Having worked on previous projects where large amounts of JUnit code was simply great big chunks of cut and paste code with minor tweaks writing tests is a much more pleasurable experience.
2. Value Objects and First Class Collections – provide a much better place to hang behaviour rather than having the same code scattered and repeated throughout services and other objects.
3. A much tighter focus on making sure that a class has only a single responsibility.
4. Shorter, more focused unit tests (generally as a result of the point above).
5. A greater awareness of when a class is too tightly coupled to other parts of the system. There are some great chapters on splitting the business logic in their application from the GUI code and making the two unaware of each other. One of the tips was take a look at the package imports to see what your class depends on, this is something I make sure I do regularly now.
6. A more considered and reduced use of Spring and an increased use of constructor arguments rather than “setter injection”.
7. Code that is easier to rewire and stub out other systems and services. This has allowed us to write a number of regression and load tools that replace our 3rd party dependencies with fakes and stubs for testing purposes.
8. A focus on a short build time, mainly due to very quick unit tests because they use mocks rather than instantiating big complicated dependencies.

I am sure there all lots more things we have taken and applied I just can’t think of them. There are still some things we have yet to try, we don’t really work from the outside in, which is an approach I would like to try. I intend to go back and read the book as it has been a while and I am sure there will be lots more things I will take away.

As my friend who read it on my recommendation said, it’s mainly just common sense, but it is common sense that you wished you had thought of and written down first! I can’t recommend GOOS highly enough, as a result of applying the principles in the book it has made me a better developer than I was before I read it and crucially it has improved the quality of the software I deliver.

The project we applied these lessons on went live about 6 months ago, I can count on a single finger the number of issues we have had which I think is an incredible achievement. The test team also commented in retrospectives as to the low defect rate and the quick turnaround on issues raised during testing.

The final thing to say is the book also changed my stance on the I for an interface debate, some of my colleagues remain to be convinced though!

I couldn’t agree with Jason more, I have seen on a number of occassions how teams can get themselves in a real pickle with their Spring configuration. Some of the problems I have encountered are:

• Excessive use of imports – context files import some other context files which in turn import more context files. I have seen the case where they then have circular dependencies as eventually they import a context file which references themselves.
• Excessive use of bean overriding – this tends to be compounded by having lots of imports over which you have no control. You may have resources that you want to mock or stub out but they get pulled in by all the imports so you end up overriding beans left, right and centre. This isn’t that easy to get working correctly as the order in which the imports occur and the beans get overridden isn’t always obvious.
• Huge test context files created – because of the problems of excessive imports and bean overriding I have seen developers copy and paste the small bits they want to test out of the real contexts and into a test context defining the stubs/mocks they then need. Now this is obviously a lot simpler for them as everything is in one context file and they can see what is happening. However it’s not much use to put it mildly, now you are only testing a test context and not what actually gets deployed. With this state of affairs it is easy to make a change to a context file or code that would break everything yet still have all the tests pass and only at deploy/run time do you discover there is an issue.

So how can we avoid getting into such a pickle? I find that using a composite approach to building the Spring contexts works well. To explain what I mean by this let’s take an example.

Say we have a simple service that uses JPA to achieve it’s goals. We might have a big unwieldy spring context that looks like:

<?xml version="1.0" encoding="utf-8"?>
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:tx="http://www.springframework.org/schema/tx"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">

 <bean id="myService">
   <property name="entityManagerFactory" ref="myEntityManagerFactory" />
 </bean>

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

 <bean id="myEntityManagerFactory">
   <property name="persistenceUnitName" value="my-persistence-unit" />
   <property name="dataSource" ref="myDatasource" />
   <property name="jpaVendorAdapter" ref="myHibernateJpaProps" />
 </bean>

 <bean id="myDatasource">
   <property name="driverClassName" value="oracle.jdbc.OracleDriver" />
   <property name="url" value="jdbc:oracle:thin:@localhost:1521:MYDATABASE" />
   <property name="username" value="username" />
   <property name="password" value="password" />
 </bean>

 <bean id="myHibernateJpaProps">
   <property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect" />
 </bean>

 <bean id="transactionManager">
   <property name="entityManagerFactory" ref="myEntityManagerFactory" />
 </bean>

 <tx:annotation-driven transaction-manager="transactionManager" />
</beans>

Now this has everything in one big lump, so if in my test I don’t want to connect to an Oracle database then I would have to override the beans for the datasource and the hibernate properties. What I would do in this situation is split the contexts into two (I would perhaps actually go for three, but the principle is the same), one for the service with the entity manager factory and then the other for the beans I am likely to want to stub out. So now we have context 1:

<?xml version="1.0" encoding="utf-8"?>
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:tx="http://www.springframework.org/schema/tx"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">

 <bean id="myService">
   <property name="entityManagerFactory" ref="myEntityManagerFactory" />
 </bean>

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

 <bean id="myEntityManagerFactory">
   <property name="persistenceUnitName" value="my-persistence-unit" />
   <property name="dataSource" ref="myDatasource" />
   <property name="jpaVendorAdapter" ref="myHibernateJpaProps" />
 </bean>

 <bean id="transactionManager">
   <property name="entityManagerFactory" ref="myEntityManagerFactory" />
 </bean>

 <tx:annotation-driven transaction-manager="transactionManager" />
</beans>

Then in context 2:

<?xml version="1.0" encoding="utf-8"?>
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

 <bean id="myDatasource">
   <property name="driverClassName" value="oracle.jdbc.OracleDriver" />
   <property name="url" value="jdbc:oracle:thin:@localhost:1521:MYDATABASE" />
   <property name="username" value="username" />
   <property name="password" value="password" />
 </bean>

 <bean id="myHibernateJpaProps">
   <property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect" />
 </bean>

</beans>

Now what this means is that when we come to write a unit test we can use context 1 and then combine it with a test version of context 2 which uses an in memory HSQL database, like so:

<?xml version="1.0" encoding="utf-8"?>
<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

 <bean id="myDatasource">
   <property name="driverClassName" value="org.hsqldb.jdbcDriver" />
   <property name="url" value="jdbc:hsqldb:mem:MYINMEMORYDB" />
   <property name="username" value="sa" />
   <property name="password" value="" />
 </bean>

 <bean id="myHibernateJpaProps">
   <property name="databasePlatform" value="org.hibernate.dialect.HSQLDialect" />
 </bean>

</beans>

Using this approach we will end up with one context file at the top that composes all the spring context files it needs for an application, notice that this will be the only context that actually imports others.

It avoids excessive importing and there is no need for bean overriding as you make sure you include the context file that has the version you want. It allows you to test as much of your spring contexts as possible in unit tests before you have to then move on to integration tests or tests against a deployed system. This helps keep the build time and give you a shorter feedback loop.

I promise to blog a bit more about the things we are doing in Grails and how it is aiding our productivity.

Some of the interesting things we have used are:

• Spring Security Core Plugin – for coarse grained security restricting URLs based on roles
• Spring Security ACL Plugin – for finer grained security restricting users access to specific instances of objects
• The Google Chart Plugin – for drawing fancy charts, obviously
• The Eastwood Chart Plugin – to provide the functionality of Google Charts without calling out over the internet

The security stuff was particularly interesting especially when implementing paging on objects restricted using ACL. I will blog about this next as there doesn’t seem to be too much out there about how to achieve it successfully.

Since last blogging about JSF 2.0 and the new scopes we have done a couple of projects in Grails. I must admit that I am completely sold on Grails.

So much so that a project we were doing in JSF has been rewritten from scratch in Grails and progress has been at a far more impressive rate.

Development is being done using Springsource Tool Suite (STS) as it has Grails & Groovy integration.

One problem though is we have commited the .classpath and .project files into the repository to allow other developers to set the project up in STS (or eclipse).

Obviously this isn’t ideal and if it were a maven project then we would just use the eclipse plugin to generate the appropriate files from the command line.

Today I found that Grails actually has a very similar tool which is invoked from the command line.

Simply type grails integrate-with --eclipse and voila, you now have the appropriate .classpath and .project files.

From that point on you can import the existing project into the workspace as normal.

See this page for more information on integration with STS

In a lot of cases Request scope wasn’t adequate. An exampe is when rendering a table with command buttons on each row. When the user clicked on the button the backing bean had been thrown away after the page had been rendered and so didn’t work correctly.

The workaround for this was you had to create all you beans as Session scope or you had to write some custom components to save away the state. Neither of which is ideal.

JSF 2.0 addresses this issue and adds two new scopes (plus the ability to add custom ones). They are View and Flash scope.

The View scope addresses exactly the problem of the table with command links. The bean is preserved until the user has finished with that particular view.

For a more detailed look at the new scopes and other features of JSF 2.0 I would recommend this blog post that I came across.

So View scope is the thing that I need. The only problem I now have is that I am using Spring to manage my beans for me rather than JSF.

Since View and Flash scope are specific to JSF and not Spring they are not available straight out of the box.

Fortunately it turns out to be easy to write a custom scope in Spring and register it with the context. I found this blog which details how to do it. The instructions are for Spring 3.0 but I was using version 2.5 and it’s practically identical.

It works a treat and I am now able to use View scope quite happily!

One niggle of this approach is when creating a new workspace sometimes eclipse is unaware of the location of the maven repository and will report many build errors.

This can be fixed from the command line by running the following:

mvn eclipse:configure-workspace -Declipse.workspace=<path to workspace>

Note that previously you could use the eclipse:add-maven-repo goal but this has since been deprecated.

Many thanks to Jamie for pointing me at his blog where he has the command to pipe in the file from the command line, which works a treat!