Skip to main content


Showing posts from 2009

Adapter pattern revised

In my article about adapter pattern I have written an adapter that allows to access Ehcache cache instances through a simple Map interface. The basic idea was to write a Map implementation that actually, behind the scenes, was wrapping and hitting Ehcache. Everything looked great but Zach Bailey found a bug in my implementation – or more precisely – lack of functionality. He even provided a test case proving he is right. And sadly, he was ;-). Thank you Zach!

The problem was with three map methods: keySet(), entrySet() and values(). If you read carefully their API you’ll find out that all these methods should return an "interactive" view backed by the underlying map so that changing the view is automatically reflected in the map that returned that view and vice-versa. For example, if you remove an item from the set returned by keySet(), corresponding map entry with this key value should be also removed. Unfortunately, in my implementation these methods simply returned indepe…

Chain of responsibility pattern meets Spring, JPA, Wicket and Apache CXF part 2/2

In the first part of this article I have shown a semi-real life example of the Chain of responsibility pattern (also mentioning about Iterator, Adapter and DTO). This behavioral design pattern has been used to control the process of registering a car, consisting of several steps. Everything worked es expected but modifying the chain configuration required application restart. Also not everyone might enjoy editing Spring context XML files. We will address this issues and make our application more dynamic.

If not storing the chain configuration in Spring file directly, then where? Of course in the database, preferably using JPA. This is the JPA entity that will serve as a single handler configuration:

public class RegistrationChainHandlerConfig implements Serializable {
private int id;
private String handlerName;
private int priority;
private boolean enabled;
/* getters/setters */

Each handler configured as a Spring bean is going to have a corresponding RegistrationChainHan…

Chain of responsibility pattern meets Spring, JPA, Wicket and Apache CXF part 1/2

Chain of responsibility behavioral design pattern is a wonderful solution for complex logic of processing a requests. In this pattern single request (message, database record, external system call, etc.) is being passed to the first handler in the chain. This handler can:

process request and return resultprocess request partially and run subsequent handlerignore the request and pass the control further as aboverun next handler and, after it returns, process already handled requestsimply return, without processing and passing control down the chainthrow an exception
Of course, if the first handler decides to pass control down the chain to the second one, the second handler has the same set of options. The most important feature of handlers is that each handler is only aware of itself – it does not know its position in chain (whether it is first, last or somewhere in the middle) and particularly not know what is the next handler down the chain. Because each handler is available only throu…

My first open source contribution

Few days ago popular Apache Commons Lang library gained new utility method in Validate class: notBlank(). This also happens to be my first contribution to the open source community (see: LANG-533 and commit 828310). Use notBlank when you want to check whether the given string is not null, not empty, and does contain anything apart from whitespaces:

Validate.notBlank(" a ");
Validate.notBlank(null); //will throw IllegalArgumentException
Validate.notBlank(""); //will throw IllegalArgumentException
Validate.notBlank(" ", "Should not be blank"); //will throw IllegalArgumentException
Validate.notBlank(" \n "); //will throw IllegalArgumentException

This handy method can be used to validate user input or configuration, where single space or newline characters should also be treated as invalid. It will be available in version 3.0 of Lang library.

I know this contribution is so tiny and n…

Compile- vs load-time weaving performance in Spring

Yesterday I had pleasure to participate in Java Developers’ Day in Kraków, Poland. It was a great experience to see Mark Richards (author of Java Message Service) and Scott Davis (Groovy Recipes) giving a talk. Also I really enjoyed Wojciech Seliga speak about code review. He works for Atlassian and shown a bit of Crucible, but his main point was that code review is not about looking for bugs made by other developers. It is rather an agile process of getting to know the code.

I could write much more about JDD, of course starting from "you should regret if you haven’t been there", but I am quite sure that you are already waiting for the main topic. Let’s just say, that there is a chance that JDD will take 2 days in the next year and I will do my best to be there.

After reading my previous post one of my friends asked about performance of creating objects marked as @Configurable. He wants to inject EntityManager or other custom dependencies to his JPA POJOs but is concerned abou…

DDD in Spring made easy with AspectJ

UPDATE: Over the years I learnt that the solution provided below is not really an example of domain-driven design. It's more like an active record implementation on top of Spring. But the technical part of the article is still relevant, so I keep it intact. Before I start the main topic, I would like you to think for a while about the best JEE application design you can imagine. No matter you use Spring or EJB3, as they are very similar, probably you would suggest similar approach. Starting from the back you have:

domain objects, which are simple POJOs mapped directly to database relations. POJOs are great because JavaBean-style properties are well understood be many frameworks. data access layer – typically stateless services, which wrap up database access code (JDBC, Hibernate, JPA, iBatis or whatever you want) hiding its complexity and providing some level of (leaky) abstraction. DAOs are great because they hide nasty and awkward JDBC logic (that is why some question the need f…