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.

Does Defensive Programming Deserve Such a Bad Name?

The other day I went to an hour's talk on erlang, merely as an observer; I know nothing about erlang except that it does sound interesting and that the syntax is... well... unusual. The talk was given to some Java programmers who had recently learnt erlang and was a fair critic about their first erlang project, which they were just completing. The presenter said that these programmers needed to stop thinking like Java programmers and start thinking like erlang programmers¹ and in particular to stop programming defensively and let processes fail fast and fix the problem.

Now, apparently, this is good practice in erlang because one of the features of erlang, and please correct me if I'm wrong, is that work is split into supervisors and processes. Supervisors supervise processes, creating them, destroying them and restarting them if required. The idea of failing fast is nothing new and is defined as the technique to use when your code comes across an illegal input. When this happens your code just falls over and aborts the point being that you fix the supplier of that input rather than your code. The sub-text of what the presenter said is that Java and defensive programming is bad and fail-fast if good, which is something that really needs closer investigation.

The JSR 303 javax.validation.Payload Class - WTF???

During the course of my last few blogs I’ve covered quite a few features of the JSR 303 Valdator and there is one feature that I’ve avoided looking into until now and that's the payload attribute of the constraint annotation interface.

There’s not much on this Hibernates documentation, and I couldn't find an entry for Payload in the JSR 303 Javadocs (if you know of one please let me know), so it raises the question of what it’s for... Looking at Hibernate’s documentation it states that: “an attribute payload that can be used by clients of the Bean Validation API to assign custom payload objects to a constraint. This attribute is not used by the API itself.” From this, you’d think that wouldn’t have to include it in your custom constraint declaration, but try taking it out and nothing works. This means that the validator is reflectively checking for its presence even though it’s not using it. Something smells fishy here.

Using the JSR 303 @GroupSequence Annotation

Yesterday’s blog covered JSR 303 groups, and today’s blog builds on that idea and demonstrates how to use the @GroupSequence annotation using the beans and custom constraints mentioned previously.

If you need to find all my blogs on JSR 303, then I suggest that you click on the ‘JSR 303’ label in the cloud below. They all follow the same Address bean validation theme.

Using JSR 303 Validation Groups

Anyone who’s looked at the code for a JSR 303 custom constraint will have noticed that the annotation interface declaration contains a couple of less than obvious attributes: groups() and payload as demonstrated by the @Country custom constraint below:

@Target({ ElementType.METHOD, ElementType.FIELD })
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = CountryValidator.class)
public @interface Country {

  String message() default "{country.constraint}";

  String[] values() default "UK";

  Class<?>[] groups() default {};

  Class<? extends Payload>[] payload() default {};
}

This blog covers the groups attribute in an attempt to explain its purpose.

Adding Optional Arguments to a JSR 303 Custom Constraint

When looking at JSR 303 you may have noticed that you can add argument values to some of the built-in constraints. For example:

  @Size(min = 2, max = 25)
  private String street;

or

Adding a JSR 303 Custom Constraint to your Spring 3 Web App

In yesterday’s blog, I demonstrated how to write a JSR 303 Custom Constraint and validate it use Hibernate’s reference validator class javax.validation.Validator. Having written your constraint, the next step is to add it into your web-application, which couldn’t be easier.

Writng a JSR 303 Custom Constraint

Yesterday’s blog demonstrated how to write a Spring custom validator for an address web-app. At the same time I mentioned how that this method should really be marked as deprecated in favour of a JSR 303 custom constraint, and writing a custom constraint isn’t that complicated, it’s just a matter of implementing two basic steps:

1. Create a constraint annotation
2. Create a constraint validator

If the Hibernate Validator is on your path then these classes are picked up automatically, so there’s no need to hook things together.

I’m going back to yesterday’s contrived scenario of a Birmingham postal code validator for our Address object. As the code below demonstrates, all we want to do is to apply an

Applying a Custom Spring Validator to a Spring MVC Controller

Last month I wrote a blog demonstrating how to write a Spring validator using Spring’s Validator interface. Today’s blog demonstrates how to apply that validator to the Controller of a Spring 3 web-application.

Is the Spring Validator mechanism as friendly as it could be?

When I first came across the Spring validator classes in October 2006, I thought at the time that they weren’t particular clear. They seem fit into that realm of programming where everyone just copies what other people have done without understanding what’s going on and it all works, which is how I’ve seem them used. I guess that today it’d be called Cargo Cult programming. As you know from my previous blog, ValidationUtils will validate your target object without any obvious reference to it, which to me is confusing. You also know that you can pass null in to the Validator.validate() method for the target object, but again there’s no explanation why.

The Spring Validator Interface and Other Animals

An important part of any application is validating your user’s input and the bitter experience of spending hours debugging code that’s failed owing to bad data only serves to underline how crucial this is.

You should virtually always perform user validation at the presentation level and a top-tip is to always factor your validation code into a distinct set of objects and to avoid interweaving it in with