The Simple Story Paradox

I’ve recently been following the #isTDDDead debate between Kent Beck (@kentbeck), David Heinemeier Hansson (@dhh), and Martin Fowler (@martinfowler) with some interest. I think that it’s particularly beneficial that ideas, which are often taken for granted, can be challenged in a constructive manner. That way you can figure out if they stand up to scrutiny or fall down flat on their faces.

The discussion began with @dhh making the following points on TDD and test technique, which I hope I’ve got right. Firstly, the strict definition of TDD includes the following:

1. TTD is used to drive unit tests
2. You can’t have collaborators
3. You can’t touch the database
4. You can’t touch the File system
5. Fast Unit Tests, complete in the blink of an eye.

He went on to say that you therefore drive your system’s architecture from the use of mocks and in that way the architecture suffers damage from the drive to isolate and mock everything, whilst the mandatory enforcement of the 'red, green, refactor’ cycle is too prescriptive. He also stated that a lot of people mistake that you can’t have confidence in your code and you can’t deliver incremental functionality with tests unless you go through this mandated, well paved road of TDD.

Tracking Exceptions - Part 6 - Building an Executable Jar

If you’ve read the previous five blogs in this series, you’ll know that I’ve been building a Spring application that runs periodically to check a whole bunch of error logs for exceptions and then email you the results.

Having written the code and the tests, and being fairly certain it’ll work the next and final step is to package the whole thing up and deploy it to a production machine. The actual deployment and packaging methods will depend upon your own organisation's processes and procedures. In this example, however, I’m going to choose the simplest way possible to create and deploy an executable JAR file. The first step was completed several weeks ago, and that’s defining our output as a JAR file in the Maven POM file, which, as you’ll probably already know, is done using the packaging element:

Tracking Exceptions - Part 5 - Scheduling With Spring

It seems that I'm finally getting close to the end of this series of blogs on Error Tracking using Spring and for those who haven’t read any blogs in the series I’m writing a simple, but almost industrial strength, Spring application that scans for exceptions in log files and then generates a report. From the first blog in the series, these were my initial requirements:

1. Search a given directory and its sub-directories (possibly) looking for files of a particular type.
2. If a file is found then check its date: does it need to be searched for errors?
3. If the file is young enough to be checked then validate it, looking for exceptions.
4. If it contains exceptions, are they the ones we’re looking for or have they been excluded?
5. If it contains the kind of exceptions we’re after, then add the details to a report.
6. When all the files have been checked, format the report ready for publishing.
7. Publish the report using email or some other technique.
8. The whole thing will run at a given time every day

This blog takes a look at meeting requirement number 8: "The whole thing will run at a given time every day" and this means implementing some kind of scheduling.

Tracking Exceptions - Part 4 - Spring's Mail Sender

If you've read any of the previous blogs in this series, you may remember that I'm developing a small but almost industrial strength application that searches log files for exceptions. You may also remember that I now have a class that can contain a whole bunch of results that will need sending to any one whose interested. This will be done by implementing my simple Publisher interface shown below.

public interface Publisher {

  public <T> boolean publish(T report);
}

If you remember, the requirement was:

7 . Publish the report using email or some other technique.

In this blog I’m dealing with the concrete part of the requirement: sending a report by email.

Error Tracking Reports - Part 3 - Strategy and Package Private

This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.

If you’ve read the first blog in the series you may remember that I initially said that I needed a Report class and that “if you look at the code, you won’t find a class named Report, it was renamed Results and refactored to create a Formatter interface, the TextFormatter and HtmlFormatter classes together with the Publisher interface and EmailPublisher class”. This blog covers the design process, highlighting the reasoning behind the refactoring and how I arrived at the final implementation.

If you read on, you may think that the design logic given below is somewhat contrived. That’s because it is. The actual process of getting from the Report class to the Results class, the Formatter and Publisher interfaces together with their implementations probably only took a few seconds to dream up; however, writing it all down took some time. The design story goes like this...

Tracking Exceptions With Spring - Part 2 - Delegate Pattern

In my last blog, I started to talk about the need to figure out whether or not your application is misbehaving in it's production environment. I said that one method of monitoring your application is by checking its log files for exceptions and taking appropriate action if one is found. Obviously, log files can take up hundreds of megabytes of disk space and it's impractical and really boring to monitor them by hand.

I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.

I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.

Tracking Application Exceptions With Spring

A few weeks ago a colleague asked me to spend a week doing a support role as he needed cover whilst he took a well earned holiday and he couldn't find anyone else. As I'd just completed a particularly complex coding project and was feeling a little burnt out, I said 'yes'; after all the change would do me good.

Part of the job consisted of monitoring a collection of fairly critical backed processes, to see how well they were performing and whether or not they were going wrong.

We developers spend a lot of time and energy adding logging to our application in order to prove that it's working okay and to figure out what went wrong when an exception occurs. These log files are often used to tell us how well, or badly, our application is performing on a daily basis.

I'm ignoring other techniques such as adding probes to your application by whatever method you choose, such as HTTP or JMX. These provide immediate information on your application rather than the second level monitoring under discussion here.

There are at least three ways of monitoring log files:

Optimising Your ApplicationContext

There’s a problem with Spring, it’s been there for some time and I’ve come across it in a number of projects. It’s nothing to do with Spring, or the Guys at Spring, it’s down to Spring’s users like you and me. Let me explain… In the old days of Spring 2 you had to configure your Application Context by hand, manually creating an XML configuration file that contained all your bean definitions. The down side of this technique was that it was time-consuming to create these XML files and then, you had the headache of maintaining this increasingly complex file. I seem to remember that at the time, it was known as “Spring Config Hell”. On the upside, at least you had a central record of everything that was loaded into the context. Bowing to demand and the popular notion that annotations were the way to go, Spring 3 introduced a whole raft of stereotyping classes such as @Service, @Component, @Controller and @Repository together with an addition to the XML configuration file of the <context:component-scan/> element. This made, from a programming point of view, things a lot simpler and is a hugely popular way of constructing Spring contexts.

There is, however, a downside to using Spring annotations with wild abandon

Tomcat's Graceful Shutdown with Daemons and Shutdown Hooks

My last couple of blogs have talked about long polling and Spring's DeferredResult technique and to demonstrate these concepts I've shoehorned the code from my Producer Consumer project into a web application. Although the code demonstrates the points made by the blogs it does contain a large number of holes in its logic. Apart from the fact that in a real application you wouldn't use a simple LinkedBlockingQueue, but would choose JMS or some other industrial strength messaging service, and the fact that only one user can get hold of the match updates, there's also the problem it spawns badly behaved threads that don't close down when the JVM terminates.

You may wonder why this should be a problem…

Long Polling with Spring 3.2’s DeferredResult

In our last episode, the CEO of Agile Cowboys Inc had just hired a Java/Spring consultant by giving him the Porsche that he originally bought for his girlfriend. Being upset by the loss of her prize Porsche, the CEO’s girlfriend has told his wife of their affair. His wife, after cutting up the CEO’s suites has filed for divorce. Meanwhile the CEO has implemented a new ‘casual’ dress code at the office and the Java/Spring consultant has just arrived back from a spin in his new Porsche and is sitting down at his desk about to fix the TV company’s software... If this doesn’t mean anything to you then take a look at Long Polling Tomcat With Spring.

The Java/Spring Consultant has to fix the TV Company’s server resource problem before the next big game, and he knows he can do this by implementing Spring’s Deferred Result technique using the Servlet 3 specification as implemented on Tomcat 7¹

The first thing that the Java/Spring consultant does is to check

Long Polling Tomcat with Spring

"Ooh err Missus" as comedian Frankie Howerd would have said, but enough of British innuendo and double entendre because Long Polling Tomcat isn't some kind of sexual deviance with next door's moggy, it's a technique (or more of a hack) that's been developed as a result of Steve Jobs's refusal to support Adobe Flash Player on the iPhone and iPad. The thing is, using Flash Player as part of a web application was a really good way of supporting the Publish and Subscribe paradigm as it was able to cater for those scenarios that require live updates, such as live stock prices, news updates and changes to betting odds, whereas straight forward HTTP, with its request/reply paradigm, is a good way of supporting static pages. A good number of companies put a lot of effort in to developing applications that used Flash in order to provide their users with realtime data. When Apple announced that iOS would not support Adobe Flash they were left high and dry without an iPhone solution and to get back into the mobile market I imagine that a good number of them went for long polling.

So, what is a long poll? Well, it isn't a tall guy from Warsaw, the idea is to mimic the Publish and Subscribe pattern. The scenario goes like this:

Getting Started With Spring’s MVC Test Framework - Part 2

The first blog in this mini-series introduced the Spring MVC Test Framework and demonstrated its use in unit testing Spring MVC Controller classes as controllers rather then as POJOs. It’s now time to talk about using the framework for integration testing.

By ‘integration testing’ I mean loading the Spring context into the test environment so that the controller can work with its collaborators in ‘end to end’ tests.

Getting Started With Spring’s MVC Test Framework - Part 1

Newly promoted to the main Spring framework is the Spring MVC Test Framework, which the Guys at Spring claim is a “first class JUnit support for testing client and server side Spring MVC code through a fluent API”¹. In this and my next blog, I’m going to take a look at Spring’s MVC Test Framework and apply it to some of my existing sample code to figure out whether or not it does what it says on the tin.

The API has been designed with two ways of setting up server side tests. These are firstly, with a Spring context file and secondly, programmatically without a context file. The Guys at Spring refer to the programatic method as ‘standalone’ mode.

Setting tests up programmatically

Auditing a Spring MVC Webapp with AspectJ. Part 2

Now, this is the blog you want to read if you're interested in creating a Spring MVC Webapp that uses Aspect Oriented Programming (AOP) in the form of Aspectj's @Aspect and @Before annotations to audit a user's visit to a screen.

As I said in my last blog auditing a user’s visits to a screen is one of those few cross-cutting concerns that Aspect Oriented Programming (AOP) solves very well. The idea in the case of my demo code, is that you add an annotation to the appropriate controllers and every time a user visits a page, then that visit is recorded. Using this technique you can construct a picture of the most popular screens and therefore the most popular chunks of functionality in your application. Knowing these details makes it easier to decide where to aim your development effort as it doesn’t pay to develop those chunks of your application that hardly anyone ever uses.

For the demo-code I created a simple Spring MVC application that has two screens: a home page and a help page. On top of this I’ve created a simple annotation: @Audit, which is used to mark a controller as one that needs auditing (not all of them will, especially if you choose to audit function points rather than individual screens) and to tell the advice object the screen id. This I've demonstrated in the snippet of code below:

Auditing a Spring MVC Webapp with AspectJ. Part 1

If you’re like me, then you’ll have those kinds of programming days where everything seems to go incredibly well. You write the code and the tests and it just works. And then and there are those other kinds of days, the really bad ones, where you know that everything you’ve written is as right as it can be and the code refuses to work: something is obviously wrong, but you’ve no idea what. I had one of these kinds of days when writing the code for this blog. The idea was to demonstrate how to use Spring and Aspectj to audit a user’s visits to a screen.

Spring and the java.lang.NoSuchFieldError: NULL Exception

A few days ago I was going through a project's Maven dependencies, removing unused junk, checking jar file version numbers adding a little dependency management and generally tidying up (yes, I know that this isn't something we often get time to do, but even Maven dependencies can be a form of technical debt). After recompiling and running the unit tests I ran some end to end tests only to find that the whole thing fell apart... Big time.

The exception I got was the usual one that all Spring developers get, a

Spring MVC, Ajax and JSON Part 3 - The Client Side Code

If you’ve been following this short series of blogs on Spring, Ajax and JSON you’ll recall that I’ve got as far as creating a Spring MVC web application that displays a form, which allows the user to select a bunch of items and submit a request to the server to purchase them. The server then replies with some JSON allowing the user to confirm their purchases. If you already know all this you can now jump to HERE. If you’re wondering what I’m talking about then take a look at the first two blogs in this series:

• Spring MVC, Ajax and JSON Part 1 - Setting The Scene
• Spring MVC, Ajax and JSON Part 2 - The Server Side Code

HERE

Having completed the server side code then the next thing to do is to move on to the client side code,

Spring MVC, Ajax and JSON Part 2 - The Server Side Code

In my last blog I said that I was going to talk about Spring, Ajax and JSON, but didn't. The reason for this is that I wanted to set the scene using a (barely) credible shopping web site scenario. In this scenario when the user clicks on the eCommerce page link, the server app loads some the items from a catalogue and displays them on the page. The user then checks a number of items and presses 'Confirm Purchase'. Now, this is where Ajax and JSON come in, on pressing 'Confirm Purchase' the browser makes an Ajax request to the server sending it the item ids. The server then retrieves the items from the database returns them as JSON to the browser. The browser then processes the JSON, displaying the items on he screen.

My last blog got as far as creating and displaying a form that presented a list of items from the imaginary catalogue to the user. This blog takes a look at the next step in the project: creating some JSON.

Spring MVC, Ajax and JSON Part 1 - Setting The Scene

I've been thinking about writing a blog on Spring, Ajax and JSON for a good while, but I've never got around to it. This was mainly because it was quite complicated and the technique required has been in a state of flux. When I decided to write this blog, I had a scout around the Internet and if you look on places such as Stack Overflow you'll see many different and often contradictory answers to the question "how do I write a Spring Ajax/JSON application?" I think that this is fault of the Guys at Spring in that they've been really busy improving Spring's support for JSon; not only that the Guys at JQuery have also been busy, which means that overall things have changed dramatically over the last couple of years and the answers to this "how do I write a Spring Ajax/JSON application?" are out of date.

Just What Are Spring 3.2 Matrix Variables? - Part 2: The Code

My last blog on Spring's support for Matrix Variables concentrated on explaining what they were and why you'd want to use them. Having sorted out the what and the why, this blog is all about the how and how you use them. I also gave several examples of Matrix URIs and so, it seems good idea to demonstrate some code that processes a couple of them.