I’ve since recommended it several times to other people who were interested in building applications new applications. Most of the this feedback has been extremely positive so I’ve managed to get around to having another look at it recently. After @snaglepus suggested I check out Build twitter in Grails in 40 minutes (registration is required) I have to say I was very impressed. Since watching that I’ve gone from knowing absolutely nothing about Grails (three years it too long to keep information in memory) to building a sample application very quickly. After finding plugins for many of the tasks I wanted, I’ve implemented the logic I need and let the tool do the rest of the heavy lifting work which led to a very productive evening of coding.

I really love it when you find technology which just seems to work and does exactly what you expect it to do. There is still much I want to learn about Grails and I’m sure there are many other tips and tricks I can pick up along the way. At the minute I’m just looking through the many Grails books to find a winner and I think I have in The Definitive Guide to Grails, Second Edition. If you haven’t looked at Grails before, I really recommend you check it out and see what it can do for you. And if you aren’t following me on Twitter, I’m @pramatrdev and I’m sure there will be a few more tweets about Grails before the month is over .

Spring Recipes covers Spring 2.5 (and earlier versions) taking it from the simplest concepts right through to the most advanced level. The book is divided into nineteen chapters organised into three parts; Core, Fundamentals and Advanced. Each part builds on the previous ones to grow your understanding of all aspects of the Spring framework, for this reason the book is best read cover to cover.

This book is in no way filler and is packed full of content covering not only the Spring framework and but also several common Spring projects including; Spring Security, Spring Web Flow and Spring Web Services. For anyone that knows Spring (and it’s associated projects), this is a huge amount of information to cover in just one book, but this book really does deliver!

As the author puts it; “Reading Spring Recipes will help you master the most important 80 percent of Spring’s features with just 20 percent of the effort you would need to learn them all.” If you are already using Spring, this book will serve as an invaluable reference and companion guide for future development. If you are a newcomer to Spring, this book will serve as an excellent launch pad to get you up, running and productive with Spring very quickly.

Structure

Each of the recipes covered in the book follows; a problem, solution and then how it works approach. This approach lays out many of the common FAQ style questions that come up on Spring Forum in an accessible way; clearly outlining the problem and mapping the path to the solution. This book also acts an excellent companion to the Spring Reference manual, which is sometimes difficult to read in places and lacks the array of examples this book provides.

Audience

The intended audience for Spring Recipes, is any Java programmer hoping to learn more about Spring. No prior knowledge of Spring is required as this book covers it all right from core concepts such as inversion of control (or Ioc). This book is accessible to anyone who has heard the hype about Spring and simply wants to learn more about it and how they can leverage it’s power. This book gives Java developers hands-on experience using the Spring framework with real-world examples, this experience can be transferred straight into your Spring project.

Chapters

Part 1: Core

This part focuses on the core concepts and mechanisms of the Spring framework. The chapters in this part aim to familiarize you with Spring’s core. As a newcomer to Spring Chapter 1 introduces the concept of inversion of control the core foundation of Spring. It explains how and IoC container works, but also why it is useful and beneficial to use one. This chapter serves as an excellent introduction to IoC and is invaluable to anyone who isn’t quite sure why they should use a container based approach. This chapter is a must for anyone new to Spring or anyone trying to deliver it to a new audience.

Chapters 2-4 build on the IoC introduction, explaining how to setup and configure a new Spring project and apply the basics of Spring configuration. These first four chapters are the foundation for the rest of the book and are a must read for anyone who has never used Spring before and even advanced users may find useful hints and tips within. Chapters 5-6 cover the extremely powerful approach of AOP, introducing crosscutting concerns and how these can be configured with Spring. This technique can be extremely useful to provide trace logging, caching and other crosscutting concerns such as security. This is a must read for anyone using Spring, even if you are not directly leveraging Spring AOP or AspectJ. Spring AOP lays the foundation for introducing how Spring provides features such as transparent transaction support and method level authorization checking.

Part 2 : Fundamentals

This part has a split focus, it introduces Spring’s Data Access support, Web integration and also Testing support. Chapter 7 introduces one of the most important aspects of Spring’s data access support in the form of JdbcTemplate. This shows the reader how they can use JdbcTemplate to prevent the use of direct JDBC and instead let Spring handle all of the boiler plate code. As JdbcTemplate removes the need for the common try/catch/finally/try/catch code seen with JDBC, the code is much cleaner and much more readable. Along with this support, the Spring DataAccessException hierarchy is introduced which provides a rich set of common exceptions to provide a more granular handling approach.

Chapter 8 introduces Spring’s excellent transaction management support and explains in great detail all of the various propagation behaviours and isolation levels. This chapter is one of my favourites as it not only introduces the concept of Spring transaction support but transactions in general. It’s accessible to everyone and extremely useful when mentoring new developers.

Chapter 9 discusses how to integrate Spring with existing ORM frameworks, making their usage within the application seamless. This provides multiple approaches to integration allowing you to build on existing Spring classes, or completely decouple your classes from Spring removing the need for any Spring imports within your code. Chapters 10-11 discuss Spring’s popular MVC framework and also discuss how many other leading web frameworks can be integrated with a Spring application. As many of the projects I have worked on in the past have used Struts, Chapter 11 was particularly useful to outline all of the options available to use Spring and Struts together.

This part finishes with the introduction of Spring Testing Support, teaching you not only what features Spring has to offer but also how it integrates with popular testing frameworks such as JUnit and TestNG. As the Spring Testing support has been overhauled, it was great that this book covered the TestContextframework, but also legacy test classes to cover older versions of JUnit and TestNG. This chapter helps you leverage not only IoC for your tests but also transaction support, mock testing and also MVC integration testing. This approach enables you to easily decouple your code from your tests, providing first class support for all your testing needs.

Part 3 : Advanced

For anyone that has mastered the first twelve chapters, Chapter 13 is where things start to get really interesting. This chapter is dedicated to one of the most scary Spring projects, namely Spring Security (formerly known as Acegi). Spring Security provides a full range of authentication, authorization and access control options which allow it to secure a standalone Java application or a web-based application. This book focuses on version 2.x onwards which dramatically reduced the size of the required configuration and also its complexity. Spring Security can be a difficult subject to tackle as it’s often hard for developers to understand it’s concepts, but this chapter builds security into the example application in piecemeal steps. This demystifies many of the problematic areas of Spring Security whilst addressing the common problems a new developer might face.

Chapter 14 covers the portlet application development using the Spring Portlet MVC framework, highlighting the portlet-specific features which differ from the standard Spring MVC framework. If you don’t require the portlet features currently within your application, this chapter can safely be skipped as the next one is another gem. Chapter 15 covers the Spring Web Flow framework which addresses the three major pain–points facing web application developers: user interface navigation control, state management, and modularity. Spring Web Flow offers a flow definition language which encapsulates a reusable sequence of steps that can execute in different contexts. This framework is extremely flexible and powerful, but this chapter provides a great introduction into what is a very large subject.

Chapter 16 introduces the remoting integration that Spring provides for various technologies such as RMI, Hessian, Burlap, HTTP Invoker, and Web Services. Having already been familiar with many of these technologies, this chapter provides an excellent insight into how these can be integrated with Spring and how quickly this can be achieved. This chapter concludes with a look at Spring Web Services including how to develop contract-first web services. Chapter 17 discusses how to develop EJB 2.x and 3.0 components with Spring’s EJB support, and how to use Spring’s JMS support to simplify sending, receiving, and listening to JMS messages. This introduces a powerful concept of message-driven POJOsfor those who like the concept of message-driven beans (MDBs) but don’t want the restrictions of an EJB container.

Chapter 18 demonstrates how easily Spring beans can be exported as JMX MBeans with relative ease in comparison to the typical approach. It continues to extend this by providing remote access, auto-detection and notification. This chapter continues by introducing Spring’s email support which removes the reliance on JavaMail specific mail sessions and exceptions. This provides an abstraction which is independent making it easy to switch to another e-mail API. This chapter finishes with a look at the options available for scheduling tasks within the Spring framework, this integrates with the JDK Timer and also Quartz scheduler.

Chapter 19, this part and the book concludes with a look at the various scripting languages that can used with Spring applications including; JRuby, Groovy and BeanShell. One of the most powerful features of using scripts is that any changes made to these can be detected by Spring and thus the beans can be refreshed automatically. This is of great benefit when you wish to avoid the long compile, deploy and test cycles or the application cannot be taken down regularly for maintenance. This chapter demonstrates how scripted beans can be added to your application quickly and simply using Spring.

Summary

This book has undertaken a mammoth task, trying to squeeze Spring and associated projects all into one book. This book is very clearly written, with well-structured, concise examples that get to the heart of the problem without complicating it with unnecessary detail. The examples provide solutions to real world problems instead of taking the form of the simplistic examples found in many other technology books. My only real minor criticism of this book is it’s scope and size. Given the huge undertaking, there are obviously going to be some areas which only provide a minimal amount of information. This should be expected given the vast array of information covered, but there are a range of Apress books which can build on this foundation. I would still give this book five out of five and rate it as one of the best framework specific books I’ve read.

This book should accompany anyone starting their journey with the Spring framework and even seasoned developers. It can take you from knowing nothing about the Spring framework to knowing pretty much everything you need to create a fully functional web application with all the bells and whistles you’d expect. It provides information and examples on numerous integration points with other popular open source frameworks and languages allowing you to truly become a Spring expert. Read it, read it again and keep it on your bookshelf as a solid reference for the Spring framework.

I love a well documented API as much as the next developer. I also am fighting a constant battle to improve my JavaDoc skills, trying to write to the same quality that I see in many other projects. But is excellent documentation really enough? It can’t just be excellent when it’s written it needs to be constantly maintained to this same level over time.

It’s a pretty common occurrence that I can look at a section of code and find documentation that has nothing to do with the method it belongs to. The intention revealing name sounds nothing like the documentation which describes what it’s supposed to be doing. Somewhere in the mists of time, the intention of the method and the documentation parted company; it is documentation no more it is ex-documentation. The problem here however is that there’s nothing to catch this issue. If an extra argument is added, Eclipse might display a warning telling me it’s missing from the documentation, but the actual context of the documentation can be completely wrong and I am none the wiser.

Although this incorrect documentation may seem fairly harmless to some, the reason it was supposed to be there in the first place is to the give the user of the API information on the method contract and the expected outcomes. If this information is completely wrong however it introduces confusion and also potential misuse of the API. After much wasted time and several grey hairs later I recently filed a couple of JIRA reports about popular open source frameworks which did exactly this. After my code just didn’t work and the unit tests failed, it took me a number of minutes to realise that the JavaDoc description of expected events just didn’t reflect what was actually going on in the code.

One approach to solving this problem is to include the documentation in the frequent code reviews. Code that doesn’t have documentation or has incorrect documentation can’t be considered complete, thus doesn’t pass the review. Developers need to make sure however, that they treat the documentation with the same respect that they give to their code and their tests. When dealing with documentation I’d much sooner see a method with no documentation than something that is completely wrong. I do want a good level of documentation in the code I work on but there is a very simple rule; update it or lose it.

Just like OpenOffice, a previous project I worked on used an embedded version of HSQLDB. We had started to have several performance problems so engaged in some profiling to find potential areas for improvement. After staring at several screens full of SQL debug, one thing became apparent; our system was producing a huge number of SQL statements. This was accompanied by the realisation that it was also producing a huge number of exactly the same SQL statements.

As the embedded database was extremely fast, there had never been any performance problems before. In fact the database was not the bottleneck in many of the application operations. As the application grew more complex however, performance problems began to arise quite quickly. These problems only got worse when the numbers started to increase. Complexity + Scaling != Success. The extemely fast embedded database was now starting to be a real problem, some serious changes needed to be made.

Many of the database performance problems were resolved quite quickly by simply re-learning the most basic best practices, just because the embedded database was quick these should not have been ignored;

• Connection pooling can improve performance
• Statement caching can improve performance
• Batching statements can improve performance
• Performing SQL n + 1 selects are a bad idea regardless of how quick the database is
• Caching common SQL results can improve performance
• The database needs to be profiled to see exactly what SQL is getting executed against it

It may be possible to ignore these issues early in the project, but as the complexity increases and the application is expected to scale they can begin to be exposed. Embedded databases performance can be impressive, but make sure you handle with care.

Over the past few weeks, I’ve been reading xUnit Test Patterns (review to follow in another post), which covers making tests easier to write, understand and maintain. One important issue it discusses, is the use of assertion methods.

Assertions are a fundamental part of writing unit tests, and are typically very simple to use. Within each test, the expected outcome is expressed using assertions, each of which is boolean expression. The assertion should evaluate to true, so if the evaluation of the assertion instead returns false, the test will be failed. JUnit provides the Assert class to handle various types of common assertion. Although Assert provides a number of very simple methods, I’ve seen these frequently used inappropriately, causing unit test failures to be unnecessarily difficult to track down.

Assertion Selection

When reviewing unit tests, one of the typical activities is to ensure that assertions are being used appropriately. When developers first start to write unit tests, assertions are often used inappropriately and as such reviews can become very time consuming. Tools play a major part in development and can automate many of these kind of manual review activities. PMD is one such tool, and it provides a rule set to deal with the common JUnit problems.

One of the most common selection problems is the use of the stated outcome assertion instead of the equality assertion. When the equality assertion evaluates to false, it includes information about the two objects that should have been equal in the failure message. This information allows a developer to quickly get an idea what went wrong in the test. If the developer had used a stated outcome, (such as assertTrue), no information would have been recorded about the object state. This typically leads to extra log statements being added, or the developer has to being debugging the test.

Ensuring that the appropriate assertion is used within each unit test, is a very simple thing to do, but it gives very clear feedback about failures and allows developers to quickly track their cause.

// assertTrue("code worked", true);
// this should be removed as it serves no purpose

// assertTrue("code didn't work", false);
// Fails a test with the given message.
fail("code didn't work");

// assertTrue("actual is not empty", !actual.isEmpty());
// Asserts that a condition is false.
assertFalse("actual is not empty", actual.isEmpty());

// assertTrue("object is null", actual == null);
// Asserts that an object is null.
assertNull("object is null", actual);

// assertTrue("object is not null", actual != null);
// Asserts that an object isn't null.
assertNotNull("object is not null", actual);

// assertTrue("objects are the same", expected == actual);
// Asserts that two objects refer to the same object.
assertSame("objects are the same", expected, actual);

// assertTrue("objects are not the same", expected != actual);
// Asserts that two objects do not refer to the same object.
assertNotSame("objects are not the same", expected, actual);

// assertTrue("objects are equal", expected.equals(actual));
// Asserts that two objects are equal.
assertEquals("objects are equal", expected, actual);

Assertion Configuration

The equality assertion method provides a very simple contract, requiring the expected and the actual value. Although the contract is simple, one of the most common problems I have encountered, is that the arguments passed in to the method are in the wrong order (e.g. the expected value argument is actually the actual value and vice versa).

Although this is a trivial issue to correct, I have seen developers waste large amounts of time trying to work out what’s wrong with the code when a unit test fails. The developer immediately start to scratch their head as the values don’t seem to make sense. Without reviewing the unit test, they dive into the code to solve the problem.

I have seen this happen countless times, and every time it happens, the developer in question can’t believe they didn’t have a look at the unit test first. The equality assertion isn’t difficult to use, you just have to remember; expected, actual…. expected, actual…. expected, actual…. expected, actual….

// assertEquals("objects are equal", actual, expected);
// Asserts that two objects are equal.
assertEquals("objects are equal", expected, actual);

Assertion Messages

xUnit Test Patterns provides an great discussion about the assertion message pattern. Most developers I’ve spoken to, do add assertion messages to their tests, and I also personally find them very useful. I completely agree with Meszaros when he says;

A well-crafted Assertion Message makes it very easy to determine which assertion failed and exactly what the symptoms were when it happened.

The assertion message should spell out exactly what the author of the test was expecting to happen. When the test fails, the message should provide enough detail for the developer to understand exactly what the problem was. The time taken to write a well-crafted assertion message, is more than paid back when the assertion fails!

// assertTrue(actual.startsWith(expected));
// Asserts that a condition is true.
assertTrue( "Actual should start with expected but actual was '"
+ actual + "' and expected was '" + expected + "'", actual.startsWith(expected));

Conclusion

If you are writing unit tests, spend a couple of minutes reading over the reference manual to see what assertion methods you have to work with. xUnit Test Patterns breaks down the types of assertion into; Single Outcome, Stated Outcome, Expected Exception, Equality, Fuzzy Equality. Understand what each assertion does and more importantly, understand when and where to use assertion. Test failures become much easier to track down, when it’s clear what went wrong. Use the right assertion, use the assertion correctly and give it a meaningful message. It really is a simple as that, what could possibly go wrong?