JDK6 and JAXB2.x (which comes with JDK6) make marshalling Java to XML and unmarshalling XML to Java a snap, almost trivial.

Example

Java to XML

package foo.bar;

import java.math.BigDecimal;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;

public class JavaToXML {
	public static void main(String[] args) throws Exception {
		JAXBContext context = JAXBContext.newInstance(Product.class);

		Marshaller m = context.createMarshaller();
		m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

		Product object = new Product();
		object.setCode("WI1");
		object.setName("Widget Number One");
		object.setPrice(BigDecimal.valueOf(300.00));

		m.marshal(object, System.out);
	}
}

XML to Java

package foo.bar;

import java.io.File;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;

public class XMLToJava {

	public static void main(String[] args) {
		try {
			JAXBContext jc = JAXBContext.newInstance(Product.class);
			Unmarshaller u = jc.createUnmarshaller();

			File f = new File("product.xml");
			Product product = (Product) u.unmarshal(f);

			System.out.println(product.getCode());
			System.out.println(product.getName());
			System.out.println(product.getPrice());
		} catch (JAXBException e) {
			e.printStackTrace();
		}
	}
}

product.java

Note: the @XmlRootElement is vital here!

package foo.bar;

import java.math.BigDecimal;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class Product {
	private String code;
	private String name;
	private BigDecimal price;

	public String getCode() {
		return code;
	}
	public void setCode(String code) {
		this.code = code;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	public BigDecimal getPrice() {
		return price;
	}
	public void setPrice(BigDecimal price) {
		this.price = price;
	}
}

product.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<product>
    <code>WI1</code>
    <name>Widget Number One</name>
    <price>300.0</price>
</product>

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

EasyMock version 2.4 introduced some new functionality – the ability to capture the arguments passed to mock objects. As ever a few lines of code speaks volumes.

Capture Example

Test Class

package foo.bar;

import static org.junit.Assert.assertEquals;

import org.easymock.Capture;
import org.easymock.EasyMock;
import org.easymock.IMocksControl;
import org.junit.Before;
import org.junit.Test;

public class TestServiceImpl {
    private Service service;
    private Dao dao;
    private IMocksControl controller;
    private final String description = "description";

    @Before
    public void setUp() throws Exception {
        controller = EasyMock.createStrictControl();
        dao = controller.createMock(Dao.class);
        service = new ServiceImpl();
        service.setDao(dao);
    }
    @Test
    public void testSave() {
        Capture <DomainObject> capturedArgument = new Capture <DomainObject>();
        dao.save(EasyMock.and(EasyMock.capture(capturedArgument), EasyMock.isA(DomainObject.class)));
        controller.replay();
        service.save(description);
        controller.verify();
        DomainObject record = capturedArgument.getValue();
        assertEquals(description, record.getDescription());
        assertEquals("getNextId", record.getId());
    }
}

Source code for classes under test after the break…….

Service Interface

package foo.bar;

public interface Service {
    void save(String description);
    void setDao(Dao dao);
}

Service Implementation

package foo.bar;

public class ServiceImpl implements Service {
    private Dao dao;

    public void save(String description) {
        DomainObject record = new DomainObject();
        record.setDescription(description);
        record.setId("getNextId");
        dao.save(record);
    }
    public void setDao(Dao dao) {
        this.dao = dao;
    }
}

Dao Interface

package foo.bar;

public interface Dao {
    public abstract void save(DomainObject record);
}

Dao Implementation

package foo.bar;

public class DaoImpl implements Dao {
    public void save(DomainObject record) {
        // do something
    }
}

Domain Object (Bean)

package foo.bar;

public class DomainObject {
    private String id;
    private String description;
    public String getDescription() {
        return description;
    }
    public void setDescription(String description) {
        this.description = description;
    }
    public String getId() {
        return id;
    }
    public void setId(String id) {
        this.id = id;
    }
}

When using Ibatis to retrieve Date type values, on Oracle 10g (some driver versions), the time portion of the value returned from the database is not mapped onto the Java object.

i.e.

In DB: 02-JAN-10 13:30:00
In Java Object after mapping: 02-JAN-10 00:00:00

The Ibatis ResultMapper, snippet, looks like this:

....
<result property="savedDate" column="SAVED_DATE" javaType="java.util.Date" jdbcType="DATE"/>
....

The Solution

1. Implement our old friend the Ibatis TypeHandlerCallback.

package foo.bar;

import java.sql.SQLException;
import java.sql.Timestamp;
import java.util.Date;

import com.ibatis.sqlmap.client.extensions.ParameterSetter;
import com.ibatis.sqlmap.client.extensions.ResultGetter;
import com.ibatis.sqlmap.client.extensions.TypeHandlerCallback;

public class CustomDateHandler implements TypeHandlerCallback {

    public Object getResult(ResultGetter getter) throws SQLException {
        final Object obj = getter.getTimestamp();
        return obj != null ? (Date) obj : null;
    }

    public void setParameter(ParameterSetter setter,Object value) throws SQLException {
        setter.setTimestamp(value != null ? new Timestamp(((Date)value).getTime()) : null);
    }

    public Object valueOf(String datetime) {
        return Timestamp.valueOf(datetime);
    }
}

2. Add Typehandlers and TypeAliases to Ibatis config

<typeAlias alias="OracleDateHandler" type="foo.bar.CustomDateHandler"/>
<typeHandler callback="OracleDateHandler" jdbcType="DATETIME" javaType="date"/>

3. Update resultMap to use new “type”

....
<result property="savedDate" column="SAVED_DATE" javaType="java.util.Date" jdbcType="DATETIME"/>
....

Important Note!

This solution deals with issues caused by certain versions of the Oracle JDBC drivers. I believe that the 11g drivers fix this issue. As ever YMMV…..

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.

You need Ibatis to perform custom processing before parameters are set on a Prepared Statement or after the results are retrieved from the result set. Maybe to convert Y/N to boolean, map results to custom objects etc

Solution

You probably want to look at implementing Ibatis’ TypeHandlerCallBack, the API docs for which are here

Example

In this example I map a “prev” or “next” coming back from the DB (as “direction”) to the Enum described in this post.

Ibatis Config

<parameterMap id="findByCompanyIdParams" class="map">
    <parameter mode="IN" property="companyId" javaType="java.lang.String" jdbcType="VARCHAR"/>
    <parameter mode="IN" property="nextKeyId" javaType="java.lang.String" jdbcType="VARCHAR"/>
    <parameter mode="IN" property="maxOccurs" javaType="java.lang.Integer" jdbcType="NUMBER"/>
    <parameter mode="IN" property="direction" javaType="OBJECT"
        typeHandler="foo.bar.PagingCriteriaDirectionTypeHandlerCallback" jdbcType="VARCHAR"/>
    <parameter mode="OUT" property="outCursor" jdbcType="ORACLECURSOR" javaType="java.sql.ResultSet"/>
</parameterMap>

Java code

package foo.bar;

import java.sql.SQLException;

import com.ibatis.sqlmap.client.extensions.ParameterSetter;
import com.ibatis.sqlmap.client.extensions.ResultGetter;
import com.ibatis.sqlmap.client.extensions.TypeHandlerCallback;
import foo.bar.MyRuntimeException;

public class PagingCriteriaDirectionTypeHandlerCallback implements TypeHandlerCallback{

	public Object getResult(ResultGetter getter) throws SQLException {
		String s = getter.getString();
		if (PagingCriteriaDirection.NEXT.getDescription().equalsIgnoreCase(s)) {
			return PagingCriteriaDirection.NEXT;
		} else if (PagingCriteriaDirection.PREV.getDescription().equalsIgnoreCase(s)) {
			return PagingCriteriaDirection.PREV;
		} else {
			throw new SQLException("Unexpected value " + s + " found where "
					+ PagingCriteriaDirection.PREV.getDescription() + " or " + PagingCriteriaDirection.NEXT.getDescription() + " was expected.");
		}
	}

	public void setParameter(ParameterSetter setter, Object parameter) throws SQLException {
		PagingCriteriaDirection direction = (PagingCriteriaDirection) parameter;

		if (direction.equals(PagingCriteriaDirection.NEXT)) {
			setter.setString(PagingCriteriaDirection.NEXT.getDescription());
		}
		else {
			setter.setString(PagingCriteriaDirection.PREV.getDescription());
		}
	}

	public Object valueOf(String s) {
	    if (PagingCriteriaDirection.NEXT.getDescription().equalsIgnoreCase(s)) {
	        return PagingCriteriaDirection.NEXT;
	    }
	    else if (PagingCriteriaDirection.PREV.getDescription().equalsIgnoreCase(s)) {
	        return PagingCriteriaDirection.PREV;
	    }
	    else {
	    	throw new MyRuntimeException("Unexpected value " + s + " found where "
					+ PagingCriteriaDirection.PREV.getDescription() + " or " + PagingCriteriaDirection.NEXT.getDescription() + " was expected.");
	    }
	}

}

This simple example of a Java 5 Enum models a PREV/NEXT you might commonly see in a web app.

package foo.bar;

public enum PagingCriteriaDirection {
    NEXT("Next"), PREV("Previous");

    private String description;

    private PagingCriteriaDirection(String desc){
        description = desc;
    }

    public String getDescription() {
    	return description;
    }

    @Override
    public String toString() {
    	return description;
    }
}