I added validation, via annotations, to a Spring “Model” bean. I needed someway to Unit Test this validation, without running the container and without initialising the Spring context.

The bean (simplified)

package foo.bar;

import javax.validation.constraints.NotNull;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;

public final class ProductModel {

    @NotNull
    @Size(max=100)
    @Pattern(regexp="[^\n^\t^\r]+", message="Long Name must not contain New Lines, Carriage Returns or Tabs")
    private String longName;

    @Size(max=20)
    private String shortName;

    // rest snipped for brevity
}

The Unit Test

package foo.bar;

import java.util.Set;

import javax.validation.ConstraintViolation;

import junit.framework.Assert;

import org.hibernate.validator.HibernateValidator;
import org.junit.Before;
import org.junit.Test;
import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean;

public class Temp {
    private LocalValidatorFactoryBean localValidatorFactory;

    @Before
    public void setup() {
        localValidatorFactory = new LocalValidatorFactoryBean();
        localValidatorFactory.setProviderClass(HibernateValidator.class);
        localValidatorFactory.afterPropertiesSet();
    }
    @Test
    public void testLongNameWithInvalidCharCausesValidationError() {
        final ProductModel productModel = new ProductModel();
        productModel.setLongName("A long name with\t a Tab character");
    	Set<ConstraintViolation<ProductModel>> constraintViolations = localValidatorFactory.validate(productModel);
    	Assert.assertTrue("Expected validation error not found", constraintViolations.size() == 1);
    }
}

More

It actually took me a few hours to work the above test out (simple as it is). If I hadn’t stumbled upon these Spring Unit Tests, I might never have got it.

So, I’m working on an existing Spring 3.x web project. This project heavily favours the use of annotations over XML configuration. As I was trawling through the source code I noticed “some wierd” syntax: “/{xxxx}” (which of course I had to look up!).

Most of the following is based upon the excellent Spring Documentation. I’ve lifted and rewritten the parts I require to serve as a condensed “aide-mémoire”.

Description

A URI Template is a URI-like string, containing one or more variable names. When you substitute values for these variables, the template becomes a URI.

For example, the URI Template

http://foo.bar.com/products/{productName}

contains the variable “productName”. If we assign the variable the value “widgetA”, the URI Template yields:

http://foo.bar.com/products/widgetA

Example

@Controller
public class ProductController {
    @RequestMapping(value="/products/{productName}, method = RequestMethod.GET)
    public String getProductDetails(@PathVariable("productName") String productName, Model model) {
        Product product = this.productService.getProduct(productName);
        model.addAttribute("productDetails", product);
        return "productDetailPage";
    }
}

So, I’m working on an existing Spring 3.x web project. This project heavily favours the use of annotations over XML configuration files. As I was trawling through the source code I noticed the “@ModelAttribute” annotation (which of course I had to look up!).

If the above background seems familiar that’s because it’s the same as for a previous Spring Annotation post I made (ed: this is in danger of turning into a mini-series)

Description

Most of the following is based upon the excellent Spring Documentation. I’ve simply lifted and rewritten the parts I require to serve as an “aide-mémoire”.

The @ModelAttribute annotation serves two purposes depending on how it is used:

At Method level

Use @ModelAttribute at the method level to provide reference data for the model. @ModelAttribute annotated methods are executed before the chosen @RequestMapping annotated handler method. They effectively pre-populate the implicit model with specific attributes, often loaded from a database. Such an attribute can then already be accessed through @ModelAttribute annotated handler method parameters in the chosen handler method, potentially with binding and validation applied to it.

In other words; a method annotated with @ModelAttribute will populate the specified “key” in the model. This happens BEFORE the @RequestMapping

At Method Parameter level

When you place @ModelAttribute on a method parameter, @ModelAttribute maps a model attribute to the specific, annotated method parameter. This is how the controller gets a reference to the object holding the data entered in the form.

Examples

Method Level

@Controller
public class MyController {
    @ModelAttribute("productsList")
    public Collection<Product> populateProducts() {
        return this.productsService.getProducts();
    }
    // @RequestMapping etc omitted for brevity
}

So, in the above example, “productsList” in the Model is populated before the the @RequestMapping is performed.

Method parameter level

@Controller
public class MyController {
    @RequestMapping(method = RequestMethod.POST)
    public String processSubmit(@ModelAttribute("product") Product myProduct, BindingResult result, SessionStatus status) {

        new ProductValidator().validate(myProduct, result);
        if (result.hasErrors()) {
            return "productForm";
        }
        else {
            this.productsService.saveProduct(myProduct);
            status.setComplete();
            return "productSaved";
        }
    }
}

In the above example “myProduct” is populated with the corresponding value from the Model.

So, I’m working on an existing Spring 3.x web project. This project heavily favours the use of annotations over XML configuration files. As I was trawling through the source code I noticed the “@PathVariable” annotation (which of course I had to look up!).

Example

Imagine you’d like to create a controller that would allow users to see view products by using a URL such as http://foo.bar.com/productDetails/someProduct

e.g.

http://foo.bar.com/productDetails/widgetA - display details for widgetA
http://foo.bar.com/productDetails/widgetB - display details for widgetB

The @PathVariable annotation makes this easy…

package foo.bar;

import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;

@Controller
public class ShowProductController {

    @RequestMapping("/productDetails/{productName}") // Handle any request of the form "/productDetails/XXXXX"
    public String showProduct(Model model, @PathVariable("productName") String productName) {
        model.addAttribute("productName", productName);
        return "showProduct"; // viewname
    }
}

What just happened?

Note the {productName} in the @RequestMapping – this is the path variable. The @PathVariable annotation on the next line captures the value and binds it to the method argument

I love Spring, who doesn’t?

One thing however that I found, until recently, a bit awkward was Unit Testing objects which were constructed and initiated via the Spring context and injected into other objects that consumed them. I have seen and used many and varied “bespoke” ways to do this, none of which I found satisfying.

This was until a collegue introduced me to the wonder that is SpringJUnit4ClassRunner. I know, I know, I should have been aware of this ages ago but as they say on millionaire “it’s easy if you know the answer”!

Solution

A few lines of code speaks more than a thousand words from me……

package foo.bar;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"daos.xml"})
public final class DaoTests {

    @Autowired
    private MyDao dao;

    @Test
    public void testLoadTitle() throws Exception {
        String result = dao.doSomething();
        assertNotNull(result);
    }
}

Whats going on?

@RunWith(SpringJUnit4ClassRunner.class)
Quoting the docs: “SpringJUnit4ClassRunner is a custom extension of JUnit4ClassRunner which provides functionality of the Spring TestContext Framework to standard JUnit 4.4+ tests by means of the TestContextManager and associated support classes and annotations.”

Basically this means that tests are going to be able to get hold of instantiated beans as defined in the Spring context files (see below).

@ContextConfiguration(locations={“daos.xml”})
This is telling the test where to get the context files containing the bean definitions. Note that if you do not provide any arguments to the annotation then a default will be looked for.

For example: If your class is named foo.bar.DaoTests, the context loader will attempt to load your application context from “classpath:/foo/bar/DaoTests-context.xml”.

@Autowired
This will autowire BY TYPE, beans found in the context. Alternatively you could use @Resource to inject the dependencies by NAME (useful if several beans are of the same type)

Conclusion

Now it’s simply the case of adding a few annotations and a few imports to be able easily write tests which use Spring beans. All in all, a very unobtrusive (and fast) process.

In this simple example (notionally checking Twitter for updates) we integrate it with Spring.

Spring Config

<bean name="checkTwitterForUpdates"
  class="org.springframework.scheduling.quartz.JobDetailBean">

       <property name="jobClass" value="test.twitterReader" />
</bean>

<bean id="cronTwitterUpdateCheckTriggerBean"
  class="org.springframework.scheduling.quartz.CronTriggerBean">

       <property name="jobDetail" ref="checkTwitterForUpdates" />
       <!-- Run every day at noon -->
       <property name="cronExpression" value="0 0 12 * * ?" />
</bean>

<bean id="scheduler"
  class="org.springframework.scheduling.quartz.SchedulerFactoryBean">

       <property name="triggers">
           <list>
               <ref bean="cronTwitterUpdateCheckTriggerBean" />
           </list>
       </property>
</bean>

You may just want to call a method on an existing object (perhaps a business object). We can use MethodInvokingJobDetailFactoryBean to do just this:

Often you just need to invoke a method on a specific object. Using the MethodInvokingJobDetailFactoryBean you can do exactly this:

<bean id="jobDetail"
  class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
    <property name="targetObject" ref="someBusinessObject"/>
    <property name="targetMethod" value="someMethod"/>
</bean>

Java

package twitter;

import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.springframework.scheduling.quartz.QuartzJobBean;

public class twitterReader extends QuartzJobBean {
    protected void executeInternal(JobExecutionContext ctx)
      throws JobExecutionException {

      // Like whatever.......
    }
}

Libraries

You can get get Quartz here

You may also need:
Simple Logging Facade for Java (SLF4J) and