Intivism

February 12, 2010

Google launches Chart API

Filed under: Uncategorized — Omri Ben Shitrit @ 9:42 am

Google announced yesterday the launching of Chart Tools.
I think it would be very interesting to see the data visualizations that will come out of the API as they are embedded into Google’s spreadsheet, etc.
Google divided the API into image charts, which are rendered by the Google server, and interactive charts, which uses a browser side java script library.

Comments (0)

February 10, 2010

Step by step unit testing with Spring 3 JSR303 validation support using eclipse and maven

Filed under: Spring, eclipse, java, jsr 303, junit 4, maven2, test driven development — Omri Ben Shitrit @ 9:06 pm

In this post I would like to show a few things:
1. How Eclipse and Maven work well together to easily set up projects using Spring 3 and other libraries (maven by example)
2. Spring’s support in JSR 303 – Validation API
3. Unit testing using JSR 303 validation API
4. Using auto wiring to provide Data Fixture for unit testing using eclipse (Thanks to Martin Harris)

We start off by creating a new project (assuming you have latest eclipse installed and the maven 2 eclipse plugin):

choose a simple project (skipping the archetype selection).
Archetype are by definition “an original pattern or model from which all other things of the same kind are made”.
This basically means maven provides us with a set of predefined project structures (what is the directory tree, which files exists in the project, etc) we can choose from, according to our task – are we creating a jar? a webapp?
These well known tasks follow a usually common project structure which is predefined by maven.
For now we will skip this and go for the simple project.

Maven, as a project dependency tool amongst other things, allows to define different artifacts as part of a larger group of work.
For now, we only have our demo application of a lunch restaurants review system.

Once the project has been created, you will notice the following directory structure:

The important things to notice:

Separate source folders for our regular code and testing code
Separate resource folders
The pom.xml file which contains the maven dependencies

Once we click the pom.xml we will get the plugin view of the file:

I have introduced a property into the file called org.springframework.version, and gave it the value 3.0.0.RELEASE, for spring’s latest release.
I got this information from the maven repository meta data on spring frame work here.
The meta data also provides the group ID and artifact ID of the spring core project (just as an example):

<?xml version="1.0" encoding="UTF-8" ?> 
<metadata>
    <groupId>org.springframework</groupId> 
    <artifactId>spring-core</artifactId> 
    <version>2.0</version> 
    <versioning>
        <release>2.0.8</release> 
        <versions>
            <version>2.0</version> 
            <version>2.0.1</version> 
            <version>2.0.2</version> 
            <version>2.0.3</version> 
            <version>2.0.4</version> 
            <version>2.0.5</version> 
            <version>2.0.6</version> 
            <version>2.0.7</version> 
            <version>2.0.8</version> 
            <version>2.5</version> 
            <version>2.5.1</version> 
            <version>2.5.2</version> 
            <version>2.5.3</version> 
            <version>2.5.4</version> 
            <version>2.5.5</version> 
            <version>2.5.6</version> 
            <version>3.0.0.RELEASE</version> 
        </versions>
        <lastUpdated>20091216174158</lastUpdated> 
    </versioning>
</metadata>

If you will switch to the dependencies view, you will be able to quickly add a dependency using the artifact ID, group ID and versioning.

Notice the use of the property we added before for the spring version.

Once we added a dependency and save the file, Maven will automatically download the jar files and add it to our build path in the project.

We can invoke this manually as well by right clicking on the project –> Maven –> Update Dependencies.

The full dependency file (pom.xml) I used for spring 3.0.0 is this:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.lab49</groupId>
  <artifactId>LunchApp</artifactId>
  <name>Lunch App</name>
  <version>0.0.1-SNAPSHOT</version>
  <description>Helps you choose your lunch!</description>
  <repositories>
      <repository>
          <id>jboss</id>
          <url>http://repository.jboss.com/maven2/</url>
      </repository>
  </repositories>
  <dependencies>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-core</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-expression</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-beans</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-aop</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-context</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-tx</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-jdbc</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-orm</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-oxm</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-context-support</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-web</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc-portlet</artifactId>
          <version>${org.springframework.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-test</artifactId>
          <version>${org.springframework.version}</version>
          <scope>test</scope>
      </dependency>
      <dependency>
          <groupId>javax.validation</groupId>
          <artifactId>validation-api</artifactId>
          <version>1.0.0.GA</version>
      </dependency>
      <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>4.7</version>
      </dependency>
      <dependency>
          <groupId>org.hibernate</groupId>
          <artifactId>hibernate-validator</artifactId>
          <version>4.0.2.GA</version>
      </dependency>
      <dependency>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-api</artifactId>
          <version>1.5.6</version>
      </dependency>
      <dependency>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-log4j12</artifactId>
          <version>1.5.6</version>
      </dependency>
      <dependency>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
          <version>1.2.15</version>
      </dependency>
  </dependencies>
  <dependencyManagement>
      <dependencies>
      </dependencies>
  </dependencyManagement>
  <properties>
      <org.springframework.version>3.0.0.RELEASE</org.springframework.version>
    </properties>
</project>

Now we will add a few classes to our domain, namely an Address class and a Review class.

We will annotate these fields using the JSR 303 Validation Annotations, and I will use the following ones:

@NotNull – marks that a field cannot be null
@Size – enforces size restrictions on a collection or a String’s length
@Min – a minimal value on field
@Max – a maximal value on a field
@Pattern – a regular expression on a String field (taken from http://regexlib.com/)

package com.lab49.lunchapp.domain;
  
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;
  
public class Address {
  
    @NotNull
    @Size(min = 1, max = 30)
    private String street;
    
    @NotNull
    @Size(min = 0, max = 30)
    private String houseNumber;
    
    @NotNull
    @Size(min = 1, max = 30)
    private String city;
    
    @NotNull
    @Size(min = 0, max = 30)
    @Pattern(regexp = "(^(?!0{5})(\\d{5})(?!-?0{4})(-?\\d{4})?$)")
    private String zipCode;
    
    @NotNull
    @Size(min = 1, max = 30)
    @Pattern(regexp = "^(?-i:A[LKSZRAEP]|C[AOT]|D[EC]|F[LM]|G[AU]|HI|I[ADLN]|K[SY]|LA|M[ADEHINOPST]|N[CDEHJMVY]|O[HKR]|P[ARW]|RI|S[CD]|T[NX]|UT|V[AIT]|W[AIVY])$")
    private String state;
    
    @NotNull
    @Size(min = 1, max = 30)
    private String country;
    
    public Address() {
        
    }
  
    public String getStreet() {
        return street;
    }
  
    public void setStreet(String street) {
        this.street = street;
    }
  
    public String getHouseNumber() {
        return houseNumber;
    }
  
    public void setHouseNumber(String houseNumber) {
        this.houseNumber = houseNumber;
    }
  
    public String getCity() {
        return city;
    }
  
    public void setCity(String city) {
        this.city = city;
    }
  
    public String getZipCode() {
        return zipCode;
    }
  
    public void setZipCode(String zipCode) {
        this.zipCode = zipCode;
    }
  
    public String getState() {
        return state;
    }
  
    public void setState(String state) {
        this.state = state;
    }
  
    public String getCountry() {
        return country;
    }
  
    public void setCountry(String country) {
        this.country = country;
    }
}

package com.lab49.lunchapp.domain;
  
import java.util.Date;
  
import javax.validation.constraints.Max;
import javax.validation.constraints.Min;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
  
public class Review {
    @NotNull
    @Size(min = 1, max = 30)
    private String title;
    
    @NotNull
    @Size(min = 1, max = 1000)
    private String body;
    
    @Min(1)
    @Max(5)
    private int starRating;    
    
    @NotNull
    private Date date;
    
    public Date getDate() {
        return date;
    }
  
    public void setDate(Date date) {
        this.date = date;
    }
  
    public Review() {
        
    }
    
    public String getTitle() {
        return title;
    }
  
    public void setTitle(String title) {
        this.title = title;
    }
  
    public String getBody() {
        return body;
    }
  
    public void setBody(String body) {
        this.body = body;
    }
  
    public int getStarRating() {
        return starRating;
    }
  
    public void setStarRating(int starRating) {
        this.starRating = starRating;
    }
}

Now we can start connecting the dots.

We create a applicationContext-lunchApp.xml file in src/main/resources:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xmlns:util="http://www.springframework.org/schema/util"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
        http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/spring-jdbc-3.0.xsd
        http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
        http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd">
    
    <context:component-scan base-package="com.lab49"/>
    
    <bean id="validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean" />
  
</beans>

We only have two elements in our beans element:

A Context Component scan element which tells spring to scan the classpath for annotated components that will be auto-registered as Spring beans. By default, the Spring-provided @Component, @Repository, @Service, and @Controller stereotypes will be detected. This tag implies the effects of the ‘annotation-config’ tag, activating @Required, @Autowired, @PostConstruct, @PreDestroy, @Resource, @PersistenceContext and @PersistenceUnit annotations in the component classes, which is usually desired for autodetected components (without external configuration).
We configure the LocalValidatorFactoryBean as spring’s default JSR 303 validator.

Keep in mind that this will trigger the default bootstrap mechanism and spring will look for a JSR 303 implementation, such as Hibernate’s, so you need to make sure its in the classpath.

We do not need to worry about it because it is part of the dependencies in pom.xml, therefore maven will automatically download the jar for us.

For the actual unit testing, we will use spring’s build JUnit support, theTestContext Framework offers full integration with JUnit 4.5+ through a custom runner.

All we need to do is annotate classes with @Runwith(SpringJUnit4ClassRunner.class).

By doing so we can code JUnit unit testing and integration testing, and enjoy various benefits from the TestContext such as dependency injection in our tests and transactional test methods among other things.

As a side note, If we do not specify an empty @TestExecutionListeners({}) annotation to disable the default listeners, our test runner would require an ApplicationContext to be configured through @ContextConfiguration.

This is not the case for us.

We can now move forward with creating a base abstract class for our tests:

package com.lab49.lunchapp.testutilities;
  
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.TestExecutionListeners;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
  
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath:applicationContext-lunchApp.xml" })
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})
public class AbstractContextBaseTest {
  
}

This class will be our base class for other unit tests and through spring will load our context and inject our dependencies.

For the JSR 303 validation of our beans in the unit tests, I will introduce another base generic utility class.

This class will be injected with the validator instance from our context by spring, and through the validation API will validate a bean. The validation is done by checking how many constraint violations are in a bean.

The generics helps us avoid casts.

package com.lab49.lunchapp.testutilities.validation;
  
import static org.junit.Assert.assertTrue;
  
import java.util.Set;
  
import javax.validation.ConstraintViolation;
import javax.validation.Validator;
  
import org.apache.log4j.Logger;
import org.springframework.beans.factory.annotation.Autowired;
  
import com.lab49.lunchapp.testutilities.AbstractContextBaseTest;
  
public class AbstractValidationTest<T> extends AbstractContextBaseTest {
    
    private static final Logger LOGGER = Logger.getLogger(AbstractValidationTest.class);
    
    @Autowired
    protected Validator validator;
    
    public Set<ConstraintViolation<T>> validate(T t) {
        return validator.validate(t);
    }
    
    public void assertValid(T t) {
        assertTrue(isValid(t));
    }
    
    public void assertInvalid(T t) {
        assertTrue(!isValid(t));
    }
  
    private boolean isValid(T t) {
        Set<ConstraintViolation<T>> violations = validate(t);
  
        for(ConstraintViolation<T> violation : violations) {
            LOGGER.debug(violation);
        }
        return (violations.size() == 0);
    }
  
}

As described in the blog post I mentioned in the beginning, we will use Spring to inject our data fixtures into the actual unit test. First, lets create a fixture:

@Component
public class AddressFixture {
    public static final String ZIP_CODE = "10028";
    public static final String STREET = "2nd Avenue";
    public static final String STATE = "NY";
    public static final String HOUSE_NUMBER = "1565";
    public static final String COUNTRY = "USA";
    public static final String CITY = "New York";
    
    public Address createAddressFixture() {
        Address address = new Address();
        address.setCity(CITY);
        address.setCountry(COUNTRY);
        address.setHouseNumber(HOUSE_NUMBER);
        address.setState(STATE);
        address.setStreet(STREET);
        address.setZipCode(ZIP_CODE);
        
        return address;
    }
}

We annotate our fixture with the @Component annotation. This marks our class as a candidate for auto-detection when using annotation-based configuration and classpath scanning.

And finally our test which we name AddressTest after the Address class in our domain package:

public class AddressTest extends AbstractValidationTest<Address> {
    
    @Autowired
    private AddressFixture addressFixture;
    private Address address;
    
    @Before
    public void setUp() {
        address = addressFixture.createAddressFixture();
    }
    
    @Test
    public void testStreet_cannotBeNull() {
        address.setStreet(null);
        assertInvalid(address);
    }
    
    @Test
    public void testStreet_cannotBeEmpty() {
        address.setStreet("");
        assertInvalid(address);
    }
    
    @Test
    public void testStreet_cannotBeTooLong() {
        address.setStreet("123456789123456789123456789123456789");
        assertInvalid(address);
    }
    
    @Test
    public void testStreet_legalValue() {
        address.setStreet("123");
        assertValid(address);
    }
    
    @Test
    public void testZipcode_illegalValue() {
        address.setZipCode("myzipcode");
        assertInvalid(address);
    }
    
    @Test
    public void testZipcode_legalValue() {
        address.setZipCode(AddressFixture.ZIP_CODE);
        assertValid(address);
    }
    
    @Test
    public void testState_legalValue() {
        address.setState(AddressFixture.STATE);
        assertValid(address);
    }
    
    @Test
    public void testState_illegalValue() {
        address.setState("MyState");
        assertInvalid(address);
    } 
}

Before I move on, I would like to point out a very cool feature of the maven plugin to download javadoc.

Say we face the following situation where we would like to know what the annotation means but we miss the javadoc:

We can just go to the JAR file under Maven dependencies and using the plugin download the javadoc:

Going back to our unit test, the Autowired tells spring to resolve the reference to the AddressFixture according to the classes known to its context. Since we marked AddressFixture as @Component and we have component scanning on, spring is aware of the existence of such a matching bean.

The tests enforce the business rules we have on the address object (legal US zipcode value for instance).

Though I’ve showed you the Address class prior to the test class, the way I actually did it was to write the AddressTest class test first, and then added the proper annotation to make the test pass, in accordance with Test Driven Development.

Last but not least we can have a suite class to run several tests that check our domain’s correctness:

package com.lab49.lunchapp.suite;
  
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
  
import com.lab49.lunchapp.domain.AddressTest;
import com.lab49.lunchapp.domain.ReviewTest;
  
@RunWith(Suite.class)
@Suite.SuiteClasses({AddressTest.class, ReviewTest.class})
public class DomainSuite {
// yes, this is empty
}

And the outcome:

Comments (1)

February 5, 2010

Condition constraints using Spring’s new expression language

Filed under: Spring, Spring Expression Language, java, programming — Omri Ben Shitrit @ 4:52 pm

After being exposed to Spring Expression Language, I thought it could be useful to harness its power to describe condition constraints on methods, as part of a growing focus on test driven development.

The idea is to describe expectations from the object’s state prior to the method’s invocation, expectation from the input and expectation from state following the method’s invocation.
Since spring expression language exposes public methods, its interesting to see how we can verify correctness using other public methods.

For this purpose I will introduce 3 simple annotations:

@ConditionContext- a spring expression to be evaluated prior to any condition checks
@Precondition – a spring expression to be evaluated prior to the method invocation and after the latter
@Postcondition – a spring expression to be evaluated after the method invocation

All of these annotations are of the same code structure:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Postcondition {
String value();
}

I’ve written a very simple service that just manages a list of products.
The service supports the following operations:

public interface FooService {

public Set<Product> getProducts();

public Product getProduct(int id);

public void insertProduct(Product product);

public void updateProduct(Product product);

public void deleteProduct(Product product);

}

Where a Product just contains an ID and price.

Before I show the behind the scenes, I would like to show the final outcome which is what I described above:

@ConditionContext("#ctx.put('sizeBefore', #self.Products.size())")
@Precondition("#arg0 != null and #arg0.Id &gt; 0")
@Postcondition("#sizeBefore + 1 == #self.Products.size() and " +
"#self.Products.?[Id == 1].size() == 1 and " +
"#self.getProduct(#arg0.Id).equals(#arg0)")
public voidinsertProduct(Product product) {
products.add(product);
}

Here are my expectations from the insertProduct method as described in the constraint (just as an example, i know there many other possible constraints which can be expressed):

As a precondition I want the input to be valid which means the product argument (arg0) is not and has a positive ID.
I can also express conditions about the service’s state prior to insert, I will show that in the post condition.
Following the insert the number of products should be incremented by 1, and I shall be able to find the added product.
The latter is expressed in two different ways:
1) the obvious one of invoking getProduct() on the Id and making sure the objects are equal.
2) getting the entire collection and finding it in the collection. I have also wanted to demonstrate SpEL, so I used the collection selection syntax it provides.
The condition context is simply a way to store information prior to method invocation.
Since you cant set variables outside the SpEL context, I used a map to store the data and I later introduce the map’s keys as variable in the SpEL context.
This is why in @Postcondition you see #sizeBefore.
How does this work?

I started by creating a small driver code:

ApplicationContext ctx = newClassPathXmlApplicationContext(newString[]{"beans.xml"});
FooService fooService = (FooService) ctx.getBean("fooService");
Product product1 = new Product();
product1.setId(1);
product1.setPrice(1);
fooService.insertProduct(product1);

Adding my AOP and bean definitions in beans.xml file:

<!-- Enabling aspect support -->
<aop:aspectj-autoproxy/>
<bean id="product" class="com.lab49.spelaspecttest.domain.Product"/>
<bean id="fooService" class="com.lab49.spelaspecttest.service.DefaultFooService"/>
<bean id="aspectBean" class="com.lab49.spelaspecttest.aspect.PointCuts"/>

I created an aspect with the following:

A Pointcut for any public method.
An Around advice (such that I can control method invocation) to handle the pre and post condition logic.
The logic is quite simple, evaluate the preconditions, if they are met execute the method, if not throw an IllegalStateException.
Following the method execution, evaluate the post conditions and do the same.

The real magic occurs in the aspect code as follows (see documentation in code):

@Aspect
public class PointCuts {

	@Pointcut("execution(public * *(..))")
	private void anyPublicOperation() {}

	@Pointcut("within(com.lab49.spelaspecttest..*)")
	private void inServiceLayer() { }

	/**
	 * Just for debugging, print methods executed in service layer
	 * @param jp
	 */
	@Before("inServiceLayer()")
	public void logServiceMethodExecution(JoinPoint jp) {
		System.out.println("Executing: " + jp.getSignature().getName());
	}	

	/**
	 * I use the public pointcut and add target and annotation to statically type the annotation variables and targen object (the service).
	 *
	 */
	@Around(value = "anyPublicOperation() && target(bean) && @annotation(conditionContext) && @annotation(precondition) && @annotation(postcondition)", argNames="bean, conditionContext, precondition, postcondition")
	public Object checkConditionConstraints(ProceedingJoinPoint pjp, Object bean, ConditionContext conditionContext, Precondition precondition, Postcondition postcondition) throws Throwable {
		System.out.println("Condition context: " + conditionContext.value());
		System.out.println("Precondition: " + precondition.value());
		System.out.println("Postcondition: " + postcondition.value());

		// SPeL action begins
		EvaluationContext context = new StandardEvaluationContext(bean);
		// I add a #self variable because the implicit this SPeL evaluates properties
		// with no object against can be confusing or inconsistent.
		context.setVariable("self", bean);
		// Add all the #arg* variables to the context, the method inputs.
		addArgumentsToContext(pjp, context);

		ExpressionParser parser = new SpelExpressionParser();
		Expression preConditionExp = parser.parseExpression(precondition.value());

		// a little syntactic sugar - we turn the keys in the map in the condition context
		// to variables in evaluating the precondition and postcondition expressions
		updateConditionContext(conditionContext, parser, context);

		// SPeL uses the class<T> generics to ease on casting return values
		boolean preconditionValue = preConditionExp.getValue(context, Boolean.class);
		System.out.println("Precondition value: " + preconditionValue);

		if(!preconditionValue) {
			throw new IllegalStateException("Precondition " + precondition.value() + " failed");
		}

		// use the JoinPoint to actually execute the underlying method
		Object retval = pjp.proceed();

		Expression postConditionExp = parser.parseExpression(postcondition.value());
		boolean postConditionValue = postConditionExp.getValue(context, Boolean.class);
		System.out.println("Postcondition value: " + postConditionValue);

		if(!postConditionValue) {
			throw new IllegalStateException("Postcondition " + postcondition.value() + " failed");
		}

		//if the postcondition is met, return the method's original return value
		return retval;
	}

	private void updateConditionContext(ConditionContext conditionContext, ExpressionParser parser, EvaluationContext context) {
		Map<String,Object> map = new HashMap<String, Object>();
		context.setVariable("ctx", map);
		Expression contextExpression = parser.parseExpression(conditionContext.value());
		contextExpression.getValue(context);

		for(Entry<String, Object> entry : map.entrySet()) {
			context.setVariable(entry.getKey(), entry.getValue());
		}
	}

	private void addArgumentsToContext(ProceedingJoinPoint pjp, EvaluationContext context) {
		Object[] args = pjp.getArgs();
		for(int i = 0; i < args.length; i++) {
			context.setVariable("arg" + i, args[i]);
		}
	}
}

Comments (0)

July 27, 2009

Multi language XMLs using XSLT and Saxon

Filed under: programming — Tags: java, localization, translation, xml, xslt — Omri Ben Shitrit @ 5:51 pm

I’ve recently encountered a need to support translating an XML into different languages.
While solutions exist to use XSLT to statically transform XML pages using a “language file” my need was a little bit different.
I needed to connect an existing translation module to be used as the translations provider, and not a static XML file.
The translation API basically accepts a key for the translation, and a list of properties which specify where to look for the translation (for example, primary language, secondary language, project name, etc).

Lets look at the static way.

translation.xml:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="multilangfile.xsl"?>
<translations>
<translation key="test">Intivism</translation>
</translations>

Now lets look at multilangfile.xsl:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" />
<xsl:key name="translate" match="translation" use="@key" />
<xsl:template match="/">
<html>
<body>
<xsl:value-of select="key('translate', 'test')" />
</body>
</html>
</xsl:template>
</xsl:stylesheet>

We use xsl:key function to search for our appropriate key in the static xml file.

The dynamic way:

We use saxon as an XSLT java framework. Saxon allows linking between java code and XSLT custom functions.
We do not specify a static xml file. We specify an empty XML file as input source when using saxon API.
We create our own XSLT function in our own name space, which is linked to our back end existing translation module.

Our multilangfile.xsl will now look like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:myfunc="http://myfunc.intivism.com" xmlns:java="http://saxon.sf.net/java-type" exclude-result-prefixes="java" xmlns:sls="java:/com.intivism.TranslateMethods">

<xsl:param name="primaryLang"/>
<xsl:param name="projectName"/>

<xsl:function  name="myfunc:translate">
<xsl:param name="key"/>
<xsl:variable name="result">
<sls:translate primaryLang="$primaryLang" projectName="$projectName" key="$key" xsl:extension-element-prefixes="sls"/>
</xsl:variable>
<xsl:value-of select="$result"/>
</xsl:function>

We will supply values to the xsl:param’s list in runtime through the transformer object (code coming up).
These will be our run time attributes for obtaining the right translation from the existing module.
The TranslateMethods class will be our entry point for handling the operations within our sls xsl name space.

import net.sf.saxon.style.ExtensionElementFactory;

public class TranslateMethods implements ExtensionElementFactory {
@Override
public Class getExtensionClass(String name) {
if(name.equals("translate")) {
return TranslationOperationElement.class;
}

return null;
}
}

While parsing the XSL, saxon will invoke our class method to get the appropriare class to handle operations in our name space.
The TranslationOperationElement class extends ExtensionInstruction and has two important methods to implement: compile and prepareAttributes.
Lets look at the class:

public class TranslationOperationElement extends ExtensionInstruction{

private Expression m_primaryLangAtt;
        private Expression m_projectNameAtt;
private Expression m_keyAtt;

@Override
public Expression compile(Executable exec) throws XPathException {
return new TranslationOperationInstruction(m_primaryLangAtt, m_projectNameAtt, m_keyAtt);
}

@Override
protected void prepareAttributes() throws XPathException {
String primaryLangAtt= getAttributeValue("", "primaryLang");
        if (primaryLangAtt==null) {
            reportAbsence("primaryLang");
            primaryLangAtt= "";
        }
        m_primaryLangAtt = makeExpression(primaryLangAtt);
       // Same for other attributes
}

private static class TranslationOperationInstruction extends SimpleExpression {

public TranslationOperationInstruction(Expression primaryLangAtt, Expression projectNameAtt, Expression keyAtt) {
Expression[] subs = {primaryLangAtt, projectNameAtt, keyAtt};
setArguments(subs);
}

public int getImplementationMethod() {
            return Expression.EVALUATE_METHOD;
        }

        public int computeCardinality() {
            return StaticProperty.EXACTLY_ONE;
        }

        public String getExpressionType() {
            return "sls:translate";
        }

        public Item evaluateItem(XPathContext context) throws XPathException {
               // this is where we connect to our translation module. The returning item will be the result of our translation.
            String primarylang = arguments[0].evaluateAsString(context).toString();
            String projectName = arguments[1].evaluateAsString(context).toString();
            String key = arguments[2].evaluateAsString(context).toString();

            return new ObjectValue(TranslationModule.translate(primaryLang, projectName, key));
        }
}
}

Putting it all together:

		TransformerFactory tFactory = TransformerFactory.newInstance();
		Transformer transformer = tFactory.newTransformer(new StreamSource("ourmultilangfile.xsl"));
                // give runtime value to our XSL parameters
		transformer.setParameter("projectName", "someValue");
		transformer.setParameter("primaryLang", "someValue");

		transformer.transform(new StreamSource("d:\\someemptyxml.xml"), new StreamResult(new FileOutputStream("output.xml")));

Comments (0)