Wednesday, December 25, 2013

java.util.Random in Java 8

One of the neat features of java.util.Random class in Java 8 is that it has been retrofitted to now return a random Stream of numbers.


For eg, to generate an infinite stream of random doubles between 0(inclusive) and 1(exclusive):

Random random = new Random();
DoubleStream doubleStream = random.doubles();

or to generate an infinite stream of integers between 0(inclusive) and 100(exclusive):

Random random = new Random();
IntStream intStream = random.ints(0, 100);


So what can this infinite random stream be used for, I will demonstrate a few scenarios, do keep in mind though that since this is an infinite stream, any terminal operations has to be done once the stream has been made limited in some way, otherwise the operation will not terminate!

For eg. to get a stream of 10 random integers and print them:
intStream.limit(10).forEach(System.out::println);

Or to generate a list of 100 random integers :

List<Integer> randomBetween0And99 = intStream
                                       .limit(100)
                                       .boxed()
                                       .collect(Collectors.toList());


For gaussian pseudo-random values, there is no stream equivalent of random.doubles(), however it is easy to come up with one with the facility that Java 8 provides:

Random random = new Random();
DoubleStream gaussianStream = Stream.generate(random::nextGaussian).mapToDouble(e -> e);

Here, I am using the Stream.generate api call passing in a Supplier which generates the next gaussian with the already available method in Random class.


So now to do something a little more interesting with the stream of pseudo-random doubles and the stream of Gaussian pseudo-random doubles, what I want to do is to get the distribution of doubles for each of these two streams, the expectation is that the distribution when plotted should be uniformly distributed for pseudo-random doubles and should be normal distributed for Gaussian pseudo-random doubles.

In the following code, I am generating such a distribution for a million pseudo-random values, this uses a lot of facilities provided by the new Java 8 Streams API:

Random random = new Random();
DoubleStream doubleStream = random.doubles(-1.0, 1.0);
LinkedHashMap<Range, Integer> rangeCountMap = doubleStream.limit(1000000)
        .boxed()
        .map(Ranges::of)
        .collect(Ranges::emptyRangeCountMap, (m, e) -> m.put(e, m.get(e) + 1), Ranges::mergeRangeCountMaps);

rangeCountMap.forEach((k, v) -> System.out.println(k.from() + "\t" + v));

and this code spits out data along these lines:
-1	49730
-0.9	49931
-0.8	50057
-0.7	50060
-0.6	49963
-0.5	50159
-0.4	49921
-0.3	49962
-0.2	50231
-0.1	49658
0	50177
0.1	49861
0.2	49947
0.3	50157
0.4	50414
0.5	50006
0.6	50038
0.7	49962
0.8	50071
0.9	49695

and similarly generating a distribution for a million Gaussian pseudo-random values:
Random random = new Random();
DoubleStream gaussianStream = Stream.generate(random::nextGaussian).mapToDouble(e -> e);
LinkedHashMap<Range, Integer> gaussianRangeCountMap =
        gaussianStream
                .filter(e -> (e >= -1.0 && e < 1.0))
                .limit(1000000)
                .boxed()
                .map(Ranges::of)
                .collect(Ranges::emptyRangeCountMap, (m, e) -> m.put(e, m.get(e) + 1), Ranges::mergeRangeCountMaps);

gaussianRangeCountMap.forEach((k, v) -> System.out.println(k.from() + "\t" + v));

Plotting the data gives the expected result:

For a pseudo-random Data:


And for Gaussian Data:


Complete code is available in a gist here - https://gist.github.com/bijukunjummen/8129250

Monday, December 23, 2013

Java 8 parameter name at runtime

Java 8 will be introducing an easier way to discover the parameter names of methods and constructors.

Prior to Java 8, the way to find the parameter names is by turning the debug symbols on at the compilation stage which adds meta information about the parameter names in the generated class files then to extract the information which is complicated and requires manipulating the byte code to get to the parameter names.

With Java 8, though the compilation step with debug symbols on is still required to get the parameter names into the class byte code, the extraction of this information is way simpler and is supported with Java reflection, for eg. Consider a simple class:

public class Bot {
    private final String name;
    private final String author;
    private final int rating;
    private final int score;

    public Bot(String name, String author, int rating, int score) {
        this.name = name;
        this.author = author;
        this.rating = rating;
        this.score = score;
    }
    
    ...
}    

theoretically, a code along these lines should get hold of the parameter names of the constructor above:

Class<Bot> clazz = Bot.class;
Constructor ctor = clazz.getConstructor(String.class, String.class, int.class, int.class);
Parameter[] ctorParameters =ctor.getParameters();

for (Parameter param: ctorParameters) {
    System.out.println(param.isNamePresent() + ":" + param.getName());
}

Parameter is a new reflection type which encapsulates this information. In my tests with Java Developer Preview (b120), I couldn't get this to work though!


Update: Based on a suggestion in the comments, the way to get the parameter name information into the class byte code is using a "-parameters" compiler argument, for eg this way through maven-compiler plugin:
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>3.1</version>
 <configuration>
  <source>1.8</source>
  <target>1.8</target>
        <compilerArgument>-parameters</compilerArgument>
 </configuration>
</plugin>

References:

http://openjdk.java.net/jeps/118

Thursday, October 17, 2013

Comparator as a Functional interface in Java 8

Comparator seemingly has two abstract methods but still has been tagged as a FunctionalInterface in Java 8. Consider the following:

@FunctionalInterface
public interface Comparator<T> {

    int compare(T o1, T o2);

    /**
     * ....
     * Note that it is <i>always</i> safe <i>not</i> to override
     * <tt>Object.equals(Object)</tt>.  However, overriding this method may,
     * in some cases, improve performance by allowing programs to determine
     * that two distinct comparators impose the same order.
     * ...
     */
    boolean equals(Object obj);
    
    ....

}

Based on a couple of references(included at the end) that I saw in StackOverflow, the reason apparently is just to document the additional benefits of overriding equals in classes implementing Comparator. So even though Comparator does have two abstract methods, only one of them is truly abstract thus satisfying the requirements of a Functional Interface.


References:

StackOverflow - Why does Comparator declare equals
Lambda FAQ has a small note on equals in Comparator.

Saturday, September 28, 2013

Spring 4 Conditional

Spring 4 is introducing a new feature called Conditional - an annotation targeted towards Spring components which generate beans and vetos the generation of these beans, in essence it provides a way to conditionally generate beans.

Consider a simple example:

I have a service called "CustomerService", with two implementations of this service, say "CustomerService1" and "CustomerService2". Based on the presence of a System property, say "servicedefault", I want to create the default "CustomerService1" implementation and if it is absent I want to create an instance of "CustomerService2".

Using Java configuration based Spring bean definition I would do it this way:

@Configuration
public static class ContextConfig {
 @Bean
 public CustomerService customerService() {
  if (System.getProperty("servicedefault")!=null) {
   return new CustomerServiceImpl1();
  }

  return new CustomerServiceImpl2();
 }
}

An alternate approach is to use Spring Bean Profiles introduced with Spring 3.1:

@Bean
@Profile("default")
public CustomerService service1() {
 return new CustomerServiceImpl1();
}

@Bean
@Profile("prod")
public CustomerService service2() {
 return new CustomerServiceImpl2();
}


However, Profiles in this specific instance is a bit unwieldy as it will be difficult to set a profile for managing the implementation strategy of one bean, it is much more appropriate for cases where the behavior for a set of beans needs to be controlled.


Spring 4 introduces Conditional annotation where this behavior can be achieved in a little more reusable way.

Conditional depends on a set of Condition classes to specify the predicate, this way:

class HardCodedSystemPropertyPresentCondition implements Condition {
 @Override
 public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
  return (System.getProperty("servicedefault") != null);
 }
}

class HardCodedSystemPropertyAbsentCondition implements Condition {
 @Override
 public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
  return (System.getProperty("servicedefault") == null);
 }
}

I need two predicates, one to specify the positive condition and one to specify the negative condition, these can now be applied on the bean definitions:

@Bean
@Conditional(HardCodedSystemPropertyPresentCondition.class)
public CustomerService service1() {
 return new CustomerServiceImpl1();
}

@Bean
@Conditional(HardCodedSystemPropertyAbsentCondition.class)
public CustomerService service2() {
 return new CustomerServiceImpl2();
}

However, note that there is a hardcoded system property name "servicedefault" in the code of the Condition, this can be cleaned up further by using meta annotations. A new meta annotation can be defined this way:

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Conditional(OnSystemPropertyCondition.class)
public @interface ConditionalOnSystemProperty {
 public String value();
 public boolean exists() default true;
}

This meta annotation ConditionalOnSystemProperty takes in two user specified attributes - "value" for the system property name and "exists" to check whether the property exists or to check that the property does not exist. The meta annotation is tagged with @Conditional annotation which points to the Condition class to trigger for beans annotated with this new meta annotation, the Condition class is the following:

public class OnSystemPropertyCondition implements Condition {

 @Override
 public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
  Map<String, Object> attributes 
   = metadata.getAnnotationAttributes(ConditionalOnSystemProperty.class.getName());
  Boolean systemPropertyExistsCheck = (Boolean)attributes.get("exists");
  String systemProperty = (String)attributes.get("value");
  
  if ((systemPropertyExistsCheck && (System.getProperty(systemProperty) != null)) ||
    (!systemPropertyExistsCheck && (System.getProperty(systemProperty) == null))) {
   return true;
  }
  return false;
 }
}


The logic here is to get hold of the attributes defined on the @Bean instances using the meta-annotation, and to trigger the check for the presence or the absence of the system property based on the additional "exists" attribute. This reusable meta-annotation can now be defined on the @Bean instances to conditionally create the beans, this way:

@Configuration
public static class ContextConfig {
 
 @Bean
 @ConditionalOnSystemProperty("servicedefault")
 public CustomerService service1() {
  return new CustomerServiceImpl1();
 }
 
 @Bean
 @ConditionalOnSystemProperty(value="servicedefault", exists=false)
 public CustomerService service2() {
  return new CustomerServiceImpl2();
 }
}



Wrap Up
The example here is trivial and probably not very realistic and is used purely to demonstrate the Conditional feature. A far better example in Spring 4 is the way Conditional is used for modifying the behavior of Spring 3.1 based Profiles itself that I had mentioned previously, Profiles is internally now based on meta-annotation based Conditional:

@Conditional(ProfileCondition.class)
public @interface Profile {
 String[] value();
}

Friday, September 6, 2013

Spring data "Page" based bootstrap pager

Spring data "Page" provides a good abstraction for a Page of records, and has fields to access the current page that is being displayed, the count of all the records and the page size.

A good pager control can be built in jsp, given a Page of records, something like the following:



I have created a small gist with just such a jsp tag library, and it internally displays this pager using twitter bootstrap based styling. Using this tag library is simple, it just requires a "Page" as an attribute:

<util:pagination thispage="${aPage}"></util:pagination>


Here is a copy of the gist:

Monday, August 26, 2013

Reasons to consider spring-boot for your next Spring based application!

Spring-boot  provides a quick way to create a Spring based application. There are some very compelling reasons to consider spring-boot for your next project:

Reason 1 : Simpler Dependency management using spring-boot starter projects.

Consider the effort required to start up a CRUD web application using Spring-boot, assuming that the CRUD is implemented using a h2 database with Spring-Data providing the data access abstraction. The maven pom required for such a project is the following:

<?xml version="1.0" encoding="UTF-8"?>
<project ...

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>0.5.0.BUILD-SNAPSHOT</version>
    </parent>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
  <dependency>
   <groupId>org.thymeleaf</groupId>
   <artifactId>thymeleaf-spring3</artifactId>
  </dependency>
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-jetty</artifactId>
  </dependency>  
  <dependency>
   <groupId>org.hsqldb</groupId>
   <artifactId>hsqldb</artifactId>
   <scope>runtime</scope>
  </dependency>  
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.hamcrest</groupId>
   <artifactId>hamcrest-library</artifactId>
   <scope>test</scope>
  </dependency>      
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>           
        </plugins>
    </build>

</project>


I have removed a few things for brevity.

Now, compare this to a traditional pom.xml where all the dependencies are typically spelled out:

.....

 <dependencies>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.11</version>
   <scope>test</scope>
  </dependency>
  <dependency>
   <groupId>org.hamcrest</groupId>
   <artifactId>hamcrest-core</artifactId>
   <version>1.2.1</version>
  </dependency>
  <dependency>
   <groupId>org.hamcrest</groupId>
   <artifactId>hamcrest-library</artifactId>
   <version>1.2.1</version>
  </dependency>

  <dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.16</version>
  </dependency>
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>${slf4j.version}</version>
  </dependency>
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
   <version>${slf4j.version}</version>
  </dependency>
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-log4j12</artifactId>
   <version>${slf4j.version}</version>
  </dependency>
  <dependency>
   <groupId>org.aspectj</groupId>
   <artifactId>aspectjrt</artifactId>
   <version>${aspectj.version}</version>
  </dependency>
  <dependency>
   <groupId>org.aspectj</groupId>
   <artifactId>aspectjweaver</artifactId>
   <version>${aspectj.version}</version>
  </dependency>
        <!-- dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.0.1</version>
            <scope>provided</scope>
        </dependency>        
  <dependency>
   <groupId>net.sf.flexjson</groupId>
   <artifactId>flexjson</artifactId>
   <version>2.0</version>
  </dependency>
  <!-- Spring dependencies -->
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
   <version>${spring.version}</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-test</artifactId>
   <version>${spring.version}</version>
   <scope>test</scope>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-context</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-aop</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-aspects</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-tx</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>com.h2database</groupId>
   <artifactId>h2</artifactId>
   <version>${h2.version}</version>
  </dependency>
  <dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>${hibernate.version}</version>
  </dependency>
  <dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-entitymanager</artifactId>
   <version>${hibernate.version}</version>
   <exclusions>
    <exclusion>
     <groupId>cglib</groupId>
     <artifactId>cglib</artifactId>
    </exclusion>
    <exclusion>
     <groupId>dom4j</groupId>
     <artifactId>dom4j</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.hibernate.javax.persistence</groupId>
   <artifactId>hibernate-jpa-2.0-api</artifactId>
   <version>1.0.0.Final</version>
  </dependency>
  <dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-validator</artifactId>
   <version>4.3.0.Final</version>
   <exclusions>
    <exclusion>
     <groupId>javax.xml.bind</groupId>
     <artifactId>jaxb-api</artifactId>
    </exclusion>
    <exclusion>
     <groupId>com.sun.xml.bind</groupId>
     <artifactId>jaxb-impl</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>javax.validation</groupId>
   <artifactId>validation-api</artifactId>
   <version>1.0.0.GA</version>
  </dependency>

  <dependency>
   <groupId>javax.transaction</groupId>
   <artifactId>jta</artifactId>
   <version>1.1</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-jdbc</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-orm</artifactId>
   <version>${spring.version}</version>
  </dependency>
  <dependency>
   <groupId>commons-pool</groupId>
   <artifactId>commons-pool</artifactId>
   <version>1.5.4</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>commons-io</groupId>
   <artifactId>commons-io</artifactId>
   <version>2.4</version>
  </dependency>  
  <dependency>
   <groupId>commons-dbcp</groupId>
   <artifactId>commons-dbcp</artifactId>
   <version>1.3</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
    <exclusion>
     <groupId>commons-pool</groupId>
     <artifactId>commons-pool</artifactId>
    </exclusion>
    <exclusion>
     <groupId>xerces</groupId>
     <artifactId>xerces</artifactId>
    </exclusion>
    <exclusion>
     <groupId>xerces</groupId>
     <artifactId>xercesImpl</artifactId>
    </exclusion>
    <exclusion>
     <groupId>xml-apis</groupId>
     <artifactId>xml-apis</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <!-- Jackson JSON Processor -->
  <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-core</artifactId>
      <version>2.2.1</version>
  </dependency>
  <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.2.1</version>
  </dependency>
  <dependency>
      <groupId>com.fasterxml.jackson.module</groupId>
      <artifactId>jackson-module-jaxb-annotations</artifactId>
      <version>2.2.1</version>
  </dependency>
  <dependency>
   <groupId>org.apache.tiles</groupId>
   <artifactId>tiles-core</artifactId>
   <version>2.2.1</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.apache.tiles</groupId>
   <artifactId>tiles-jsp</artifactId>
   <version>2.2.1</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-web</artifactId>
   <version>${spring.version}</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-webmvc</artifactId>
   <version>${spring.version}</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>commons-digester</groupId>
   <artifactId>commons-digester</artifactId>
   <version>2.0</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>commons-fileupload</groupId>
   <artifactId>commons-fileupload</artifactId>
   <version>1.2.1</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.apache.commons</groupId>
   <artifactId>commons-lang3</artifactId>
   <version>3.1</version>
  </dependency>
  <dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>jstl</artifactId>
   <version>1.2</version>
  </dependency>
  <dependency>
   <groupId>javax.el</groupId>
   <artifactId>el-api</artifactId>
   <version>1.0</version>
   <scope>provided</scope>
  </dependency>
  <dependency>
   <groupId>joda-time</groupId>
   <artifactId>joda-time</artifactId>
   <version>1.6</version>
  </dependency>
  <dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>jsp-api</artifactId>
   <version>2.1</version>
   <scope>provided</scope>
  </dependency>
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-core</artifactId>
   <version>${spring-security.version}</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-config</artifactId>
   <version>${spring-security.version}</version>
   <exclusions>
    <exclusion>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
    </exclusion>
   </exclusions>
  </dependency>
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-web</artifactId>
   <version>${spring-security.version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-taglibs</artifactId>
   <version>${spring-security.version}</version>
  </dependency>
  <dependency>
      <groupId>com.googlecode.flyway</groupId>
      <artifactId>flyway-core</artifactId>
      <version>1.7</version>
  </dependency>
  <dependency>
   <groupId>org.springframework.data</groupId>
   <artifactId>spring-data-jpa</artifactId>
   <version>${spring-data-jpa.version}</version>
  </dependency>   
 
    
 </dependencies>
...

This is indeed a massive improvement in the way Spring specific dependencies are managed.

Reason 2: Quick standalone mode with auto configuration
All that needs to be done to start up a working web application is to run - "mvn spring:boot" and Spring boot does the rest. It provides a way to quickly run the application with an embedded tomcat or jetty container and auto-configures the application based on the libraries available in the classpath without needing any explicit configuration to be provided by the user - for eg. if it finds hsqldb libraries in the classpath it automatically configures a datasource with hsqldb as the embedded database, if it finds thymeleaf jars in the classpath it automatically configures thymeleaf as the templating engine, if it finds hibernate libraries in the classpath then it automatically uses hibernate as the JPA provider. This allows for a progressive enhancement in the development of a working application - Spring boot provides a way for a developer to quickly bootstrap and prototype the application and then slowly replace some of the auto-configured components with more robust alternatives - say a Postgres DB instead of hsqldb etc.

Reason 3: Opinionated Dependencies
Spring boot provides an opinionated and well tested set of dependencies that work well with the Spring ecosystem of projects. for eg. logback with slf4j as the logging dependency, using Servlet 3.0+ apis, Jackson 2.2 for json handling, thymeleaf for web page templating.


Conclusion:
The Spring-boot project is still under heavy development but even in its current state it holds a lot of potential in greatly simplifying application development using Spring umbrella of projects.


Here is a small reference application using Spring-boot - https://github.com/bijukunjummen/spring-boot-mvc-test.git



Monday, August 12, 2013

Spring based applications and logging dependencies

There is not much to say on the topic of Spring based applications and adding logging dependencies apart from pointing to the excellent blog entry at the Spring site itself - http://blog.springsource.org/2009/12/04/logging-dependencies-in-spring/

This is an old entry, but is still valid. The essence of the article is that Spring has one core logging dependency - on Apache Commons Logging. Given this dependency, there are two good options for Spring based applications.

1. Use slf4j with any of the slf4j supporting logging frameworks. This can be done by using the jcl to slf4j bridge library that slf4j provides, along with any of the compile time binding to a logging framework. say for eg, with log4j the following would be the maven dependencies:

<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-core</artifactId>
 <version>${spring.version}</version>
 <exclusions>
  <exclusion>
   <artifactId>commons-logging</artifactId>
   <groupId>commons-logging</groupId>
  </exclusion>
 </exclusions>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>jcl-over-slf4j</artifactId>
 <version>1.7.5</version>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-api</artifactId>
 <version>1.7.5</version>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-log4j12</artifactId>
 <version>1.7.5</version>
</dependency>
<dependency>
 <groupId>log4j</groupId>
 <artifactId>log4j</artifactId>
 <version>1.2.17</version>
</dependency>

There are 5 dependencies here - the commons-logging is being explicitly excluded first, then a jcl-over-slf4j library provides a JCL adapter to the slf4j library, then the slf4j api is required, the binding to log4j and finally the log4j library.


2. A better option is to use logback as the logging library. Logback natively supports slf4j api, so the dependencies is much more simplified:

<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-core</artifactId>
 <version>${spring.version}</version>
 <exclusions>
  <exclusion>
   <artifactId>commons-logging</artifactId>
   <groupId>commons-logging</groupId>
  </exclusion>
 </exclusions>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>jcl-over-slf4j</artifactId>
 <version>1.7.5</version>
</dependency>
<dependency>
 <groupId>ch.qos.logback</groupId>
 <artifactId>logback-classic</artifactId>
 <version>1.0.13</version>
</dependency>

References:
Springsource Blog entry by Dave Syer: http://blog.springsource.org/2009/12/04/logging-dependencies-in-spring/

Slf4J legacy bridge: http://www.slf4j.org/legacy.html

Logback logging library: http://logback.qos.ch/

Thursday, August 1, 2013

Spring - Autowiring multiple beans of the same type and @Primary annotation

Consider a simple Spring annotation based context, with two beans with @Service annotation, but of the same type:

@Service 
public class CustomerServiceImpl1 implements CustomerService{
 @Override
 public Customer getCustomer(long id) {
  return new Customer(1, "Test1");
 }
}

and

@Service 
public class CustomerServiceImpl2 implements CustomerService{
 @Override
 public Customer getCustomer(long id) {
  return new Customer(1, "Test1");
 }
}

Now, a client which injects in the CustomerService bean as a dependency will fail, as by default the injection of autowired fields is by type and there are two beans in the context of the same type. An error message along these lines is typically what is seen at startup:

org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type [pkg.CustomerService] is defined: expected single matching bean but found 2: customerServiceImpl2,customerServiceImpl1

A standard fix for this is to inject by bean name instead of by type, this way:

public class ConfigTest
{
    @Autowired
    @Qualifier("customerServiceImpl1")
    private CustomerService customerService;
    ...
}    

Note that I have made use of the bean naming convention for stereotype annotations which is described in more detail here

However there is another way to disambiguate which specific bean to inject in, and this is with the @Primary annotation. This annotation indicates that the target bean should be given precedence when autowiring by type. This begs the question, what happens if more than one bean of the same type is annotated with @Primary, well Spring will raise an exception like before. @Primary is expected to be applied on only bean of a specific type.

@Primary is also supported in Java Configuration, so @Bean methods can also be tagged with @Primary to indicate the higher precedence.

@Configuration
public class TestConfiguration
{
 @Bean
 @Primary
 public CustomerService customerService1() {
  return new CustomerServiceImpl1();
 }
 
 @Bean
 public CustomerService customerService2() {
  return new CustomerServiceImpl2();
 } 
}

Tuesday, July 16, 2013

Spring @Bean and PropertyPlaceHolderConfigurer

I was recently stumped by what I thought was going to be a fairly straightforward implementation - Consider the following Spring Java based bean definition file (@Configuration):

package root;

...

@Configuration
@PropertySource("classpath:root/test.props")
public class SampleConfig {
 
 @Value("${test.prop}")
 private String attr;
  
 @Bean
 public SampleService sampleService() {
  return new SampleService(attr);
 }
}

Here a bean `sampleService` is being defined, this bean is initialized with an attribute that is populated using a @Value annotation using a property placeholder string ${test.prop}.

The test for this is the following:

@ContextConfiguration(classes=SampleConfig.class)
@RunWith(SpringJUnit4ClassRunner.class)
public class ConfigTest {
 @Autowired
 private SampleService sampleService;
 @Test
 public void testConfig() {
  assertThat(sampleService.aMethod(), is("testproperty"));
 }
}


which with the current implementation of SampleConfig fails, as the place holder ${test.prop} is not resolved at all. The standard fix for this is to register a PropertySourcesPlaceholderConfigurer which is a BeanFactoryPostProcessor responsible for scanning through all the registered bean definitions and injecting in the resolved placeholders. With this change in place the @Configuration file looks like this:

@Configuration
@PropertySource("classpath:root/test.props")
public class SampleConfig { 
 @Value("${test.prop}")
 private String attr;
 
 @Bean
 public SampleService sampleService() {
  return new SampleService(attr);
 }
 
 @Bean
 public PropertySourcesPlaceholderConfigurer placeHolderConfigurer() {
  return new PropertySourcesPlaceholderConfigurer();
 }
}

However, after adding in the Property resolver, the test still fails, this time the value returned by the sampleService is null, not even the placeholder value!

The reason for the issue it turns out, is that with @Configuration which internally uses annotations like @Autowired, @Value, and @PostConstruct, any BeanFactoryPostProcessor beans have to be declared with a static, modifier. Otherwise the containing @Configuration class is instantiated very early and the BeanPostProcessors responsible for resolving annotations like @Value, @Autowired etc, cannot act on it.

This fix is well documented in the javadoc of @Bean, further a message is also logged which provides the workaround:

WARN : org.springframework.context.annotation.ConfigurationClassEnhancer - @Bean method RootConfig.placeHolderConfigurer is non-static and returns an object assignable to Spring's BeanFactoryPostProcessor interface. This will result in a failure to process annotations such as @Autowired, @Resource and @PostConstruct within the method's declaring @Configuration class. Add the 'static' modifier to this method to avoid these container lifecycle issues; see @Bean Javadoc for complete details


So with this fix the new working configuration is the following:

@Configuration
@PropertySource("classpath:root/test.props")
public class SampleConfig { 
 @Value("${test.prop}")
 private String attr;
 
 @Bean
 public SampleService sampleService() {
  return new SampleService(attr);
 }
 
 @Bean
 public static PropertySourcesPlaceholderConfigurer placeHolderConfigurer() {
  return new PropertySourcesPlaceholderConfigurer();
 }
}


References:

Monday, July 8, 2013

AbstractAnnotationConfigDispatcherServletInitializer - Long and short of it

AbstractAnnotationConfigDispatcherServletInitializer is a newly(3.2+ versions of Spring) introduced Template Method based base class that makes Spring pure java based web application Configuration(@Configuration) without using a web.xml, easier.

The use of this class can be better appreciated using an example. Prior to AbstractAnnotationConfigDispatcherServletInitializer, the way to configure a web.xml less Servlet 3 web application is by implementing a WebApplicationInitializer:

public class CustomWebAppInitializer implements WebApplicationInitializer {

 @Override
 public void onStartup(ServletContext container) {
  AnnotationConfigWebApplicationContext rootContext = new AnnotationConfigWebApplicationContext();
  rootContext.register(RootConfiguration.class);
  container.addListener(new ContextLoaderListener(rootContext));
  AnnotationConfigWebApplicationContext webContext = new AnnotationConfigWebApplicationContext();
  webContext.register(MvcConfiguration.class);
  DispatcherServlet dispatcherServlet = new DispatcherServlet(webContext);
  ServletRegistration.Dynamic dispatcher = container.addServlet("dispatcher", dispatcherServlet);
  dispatcher.addMapping("/");
 }
}

A little more detail of how WebApplicationInitializer works internally is described here

With the introduction of AbstractAnnotationConfigDispatcherServletInitializer, this configuration is now much simpler and far less error prone.

public class CustomWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
 @Override
 protected Class<?>[] getRootConfigClasses() {
  return new Class<?>[]{RootConfiguration.class};
 }

 @Override
 protected Class<?>[] getServletConfigClasses() {
  return new Class<?>[]{MvcConfiguration.class};
 }

 @Override
 protected String[] getServletMappings() {
  return new String[]{"/"};
 }
}


Indeed a terribly long name, but the class serves to make the initialization code much more concise and clear.

Sunday, June 30, 2013

Spring MVC - Migrating to Jackson 2

This does not really require a blog entry - migrating from Jackson 1.9.x to Jackson 2.x is extremely simple with Spring MVC 3.1+ based applications. The only thing that needs to be done is to replace the 1.9.x jar with Jackson 2.x jar, with the following new entry in a maven pom.xml file (assuming a maven project)

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.2.0</version>
</dependency>
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.2.0</version>
</dependency>

This is pretty remarkable considering the fact that the core Jackson package names have now been refactored from
"org.codehaus.jackson" to "com.fasterxml.jackson".


So how does this Spring MVC handle such migrations internally -

Spring MVC uses a component called a HttpMessageConverter as a strategy interface to convert the request body to an object representation, and to convert the response object representation to a serialized form to be sent back as a response.

Spring MVC registers a series of HttpMessageConverters to handle request bodies, this happens by default when the MVC is activated, typically using a xml Spring bean definition file this way:

<mvc:annotation-driven />

Or, when using new Java Config style of bean definition:

@Configuration
@EnableWebMvc
@ComponentScan(basePackages="mvcsample.web", 
 includeFilters=@Filter(type=FilterType.ANNOTATION, value=Controller.class))
public class WebConfig {

}


In both cases, a check for the presence of Jackson2 libraries is made by scanning for well-known classes within the jackson2 library:

private static final boolean jackson2Present =
  ClassUtils.isPresent("com.fasterxml.jackson.databind.ObjectMapper", aClassLoader) &&
    ClassUtils.isPresent("com.fasterxml.jackson.core.JsonGenerator", aClassLoader);

and assuming Jackson 2.x libraries are present, an appropriate HttpMessageConverter is registered:

if (jackson2Present) {
 messageConverters.add(new MappingJackson2HttpMessageConverter());
}

If there happen to be both the 1.9.x jars and the 2.x jars of Jackson in the classpath, then preferentially the 2.x HttpMessageConverter is registered before the 1.9.x HttpMessageConverters.

This way Spring MVC seamlessly handles the upgrade of Jackson libraries

Wednesday, June 19, 2013

Spring MVC Error handling flow

There are broadly three ways of handling an exception flow using Spring MVC, the objective being to intercept any application exception and present a friendly and informative view back to the user.

1. Using error-page tag in web.xml file:

This is a servlet specs driven approach, where the exceptions that bubble up from the application are intercepted based on either the HTTP response code or the exception type and the handler for the exception is specified using the location sub-tag this way:

<error-page>
    <error-code>500</error-code>
    <location>/500</location>
</error-page>
<error-page>
    <exception-type>java.lang.Exception</exception-type>
    <location>/uncaughtException</location>
</error-page>

If it is a Spring MVC based app, and if the intent is for a Spring MVC view to present the message, then a location should ideally be a Spring controller which can show the content and this can be done for the 2 locations above purely using Spring MVC configuration:

<mvc:view-controller path="/500" view-name="500view"/>
<mvc:view-controller path="/uncaughtException" view-name="uncaughtexception"/>


2. Registering a HandlerExceptionResolver:


HandlerExceptionResolver(s) are responsible for mapping the exception to views, the simplest approach is to register a SimpleMappingExceptionResolver that can map exception types to view names. The following is a way to register SimpleMappingExceptionResolver using Spring xml bean definition(based on Roo samples):

<bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver" p:defaultErrorView="uncaughtException">
 <property name="exceptionMappings">
  <props>
   <prop key=".DataAccessException">dataAccessFailure</prop>
   <prop key=".NoSuchRequestHandlingMethodException">resourceNotFound</prop>
   <prop key=".TypeMismatchException">resourceNotFound</prop>
   <prop key=".MissingServletRequestParameterException">resourceNotFound</prop>
  </props>
 </property>
</bean>

OR using Java Configuration based bean definition:

@Bean
public HandlerExceptionResolver handlerExceptionResolver() {
 SimpleMappingExceptionResolver exceptionResolver = new SimpleMappingExceptionResolver();
 exceptionResolver.setDefaultErrorView("uncaughtException");
 Properties mappings = new Properties();
 mappings.put(".DataAccessException", "dataAccessFailure");
 mappings.put(".NoSuchRequestHandlingMethodException", "resourceNotFound");
 mappings.put(".TypeMismatchException", "resourceNotFound");
 mappings.put(".MissingServletRequestParameterException", "resourceNotFound");
 exceptionResolver.setExceptionMappings(mappings );
 return exceptionResolver;
}


3. Using @ExceptionHandler

This is my preferred approach and there are two variations to using the @ExceptionHandler annotation.

In the first variation, @ExceptionHandler can be applied to the level of a controller class in which case the exceptions raised by the same controller @RequestMapped methods are handled by the @ExceptionHandler annotated methods.

@Controller
public class AController {
    @ExceptionHandler(IOException.class)
    public String handleIOException(IOException ex) {
      return "errorView";
    }
}

In the second variation of @ExceptionHandler, the annotation can be applied to ALL controller classes by annotating a method of @ControllerAdvice annotated class:

@ControllerAdvice
public class AControllerAdvice {
    @ExceptionHandler(IOException.class)
    public String handleIOException(IOException ex) {
      return "errorView";
    }
}


These essentially are the approaches to handling application exceptions in Spring MVC applications.

Monday, June 10, 2013

Google guava "live" transformation - forcing an eager transformation

One of the utility classes provided by Google Guava Library, Lists, has a utility method to transform lists of one type to another. The interesting feature of this transformation is that the transformation is "live", in the sense that any changes to the source list is visible in the destination list. This is done by doing the transformation only on demand by applying a transformation on request.

This is best shown with an example:

Account a1 = new Account(1, "business", "num1");
Account a2 = new Account(2, "business", "num2");
Account a3 = new Account(3, "business", "num3");

List<Account> list = Lists.newArrayList(a1, a2, a3);

List<Integer> ids = Lists.transform(list, new Function<Account, Integer>() {
 @Override 
 public Integer apply(Account input) {
  return input.getId();
 }
});

assertThat(ids, contains(1, 2, 3));

a2.setId(12);
assertThat(ids, contains(1, 12, 3));


Here a list of "Account"(s) is being transformed to a list of its corresponding ids. Any change in the id of the original objects is reflected in the transformed list.

Now, there are situations where an eager transformation may be desired - for eg. needing to cache the transformed list, or serializing the transformed list. The way to force an eager transformation is to make a copy of the lazy list, using another utility method provided by the Lists class:

Lists.newArrayList(ids)

Wednesday, May 29, 2013

Testing Spring "session" scope

In a Spring based Web application, beans can be scoped to the user "session". This essentially means that state changes to the session scoped bean are only visible in the scope of the user session.

The purpose of this entry is to simply highlight a way provided by Spring Test MVC to test components which have session scoped beans as dependencies.


Consider the example from Spring reference docs of a UserPreferences class, holding say the timeZoneId of the user:

@Component
@Scope(value="session", proxyMode=ScopedProxyMode.TARGET_CLASS)
public class UserPreferences {
 private String timeZoneId="default";
 public String getTimeZoneId() {
  return timeZoneId;
 }
 public void setTimeZoneId(String timeZoneId) {
  this.timeZoneId = timeZoneId;
 }
}

Here the scope is marked as "session" and the proxyMode is explicitly specified as TARGET_CLASS to instruct Spring to create a CGLIB proxy(as UserPreferences does not implement any other interface).

Now consider a controller making use of this session scoped bean as a dependency:

@Controller
public class HomeController {
 @Autowired private UserPreferences userPreferences;

 @RequestMapping(value="/setuserprefs")
 public String setUserPrefs(@RequestParam("timeZoneId") String timeZoneId, Model model) {
  userPreferences.setTimeZoneId(timeZoneId);
  model.addAttribute("timeZone", userPreferences.getTimeZoneId());
  return "preferences";
 }
 
 @RequestMapping(value="/gotopage")
 public String goToPage(@RequestParam("page") String page, Model model) {
  model.addAttribute("timeZone", userPreferences.getTimeZoneId());
  return page;
 }
}

Here there are two controller methods, in the first method the user preference is set and in the second method the user preference is read. If the session scoped bean is working cleanly, then the call to "/setuserprefs" in a user session should set the timeZoneId preference in the UserPreferences bean and a different call "/gotopage" in the same session should successfully retrieve the previously set preference.

Testing this is simple using Spring MVC test support now packaged with Spring-test module.

The test looks something like this:

First the bean definition for the test using Spring Java Configuration:
@Configuration
@EnableWebMvc
@ComponentScan({"scope.model","scope.services", "scope.web"})
public class ScopeConfiguration {}



and the test:

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.mock.web.MockHttpSession;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.web.WebAppConfiguration;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.web.context.WebApplicationContext;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
import static org.springframework.test.web.servlet.setup.MockMvcBuilders.*;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=ScopeConfiguration.class)
@WebAppConfiguration
public class ScopeConfigurationTest {
 
 @Autowired
 private WebApplicationContext wac;

 private MockMvc mockMvc;

 @Before
 public void setup() {
  this.mockMvc = webAppContextSetup(this.wac).build();
 }

 @Test
 public void testSessionScope() throws Exception {
  MockHttpSession mocksession = new MockHttpSession();
  this.mockMvc.perform(
    get("/setuserprefs?timeZoneId={timeZoneId}", "US/Pacific")
      .session(mocksession))
    .andExpect(model().attribute("timeZone", "US/Pacific"));
  
  this.mockMvc.perform(
    get("/gotopage?page={page}", "home")
     .session(mocksession))
    .andExpect(model().attribute("timeZone", "US/Pacific"));

  this.mockMvc.perform(
    get("/gotopage?page={page}", "home")
     .session(new MockHttpSession()))
    .andExpect(model().attribute("timeZone", "default"));
 }
}

In the test a MockHttpSession is first created to simulate a user session. The subsequent two requests are made in the context of this mock session, thus the same UserPreferences bean is expected to be visible in the controller which is asserted in the test. In the 3rd request a new session is created and this time around a different UserPreferences bean is visible in the controller which is asserted by looking for a different attribute.

This demonstrates a clean way of testing session scoped beans using Spring test MVC support.


Wednesday, May 22, 2013

Spring Integration File Polling and Tests

I recently implemented a small project where we had to poll a folder for new files and then trigger a service flow on the contents of the file.

Spring Integration is a great fit for this requirement as it comes with a channel adapter that can scan a folder for new files and then take the file through a messaging flow.

The objective of this specific article is to go over how a file poller flow can be tested.

To start with consider a simple flow implemented using the following Spring integration configuration:

<beans:beans xmlns="http://www.springframework.org/schema/integration"
    .....
 <channel id="fileChannel"></channel>
 <channel id="processedFileChannel"></channel>

 <int-file:inbound-channel-adapter directory="${inbound.folder}" channel="fileChannel" filename-pattern="*.*">
  <poller fixed-delay="5000"></poller>
 </int-file:inbound-channel-adapter>
 
 <service-activator input-channel="fileChannel" ref="fileHandlerService" method="handle" output-channel="processedFileChannel">
 </service-activator>
 
 <logging-channel-adapter id="loggingChannelAdapter" channel="processedFileChannel"></logging-channel-adapter>
 
 <beans:bean name="fileHandlerService" class="files.RealFileHandlingService"/>
 <context:property-placeholder properties-ref="localProps" local-override="true"/>
 
 <util:properties id="localProps">
 </util:properties>
</beans:beans>

This is better represented in a diagram:



Simple Testing of the flow

Now to test this flow, my first approach was to put a sample file into a folder in the classpath, dynamically discover and use this folder name during test and to write the final message into a test channel and assert on the messages coming into this channel. This is how the test configuration which composes the original Spring config looks like:

<beans:beans xmlns="http://www.springframework.org/schema/integration"
    ....
 <beans:import resource="si-fileprocessing.xml"/>
 <util:properties id="localProps">
  <beans:prop key="inbound.folder">#{new java.io.File(T(java.io.File).getResource("/samplefolder/samplefile.txt").toURI()).parent}</beans:prop>
 </util:properties>
 <channel id="testChannel">
  <queue/>
 </channel>
 
 <bridge id="loggingChannelAdapter" input-channel="processedFileChannel" output-channel="testChannel"></bridge>
</beans:beans>

and the test looks like this:
@Autowired @Qualifier("testChannel") PollableChannel testChannel;

@Test
public void testService() throws Exception{
 Message<?> message = this.testChannel.receive(5000);
 assertThat((String)message.getPayload(), equalTo("Test Sample file content"));
}

This works neatly, especially note that the path can be entirely provided in the configuration using a Spring-EL expression :
#{new java.io.File(T(java.io.File).getResource("/samplefolder/samplefile.txt").toURI()).parent}

Mocking out the Service

Now, to take it a little further, what if I want to mock the service that is processing the file (files.RealFileHandlingService). There is an issue here which will become clear once the mock is implemented. An approach to injecting in a mock service is to use Mockito and a helper function that it provides to create a mock this way using Spring configuration file:

<beans:bean name="fileHandlerService" factory-method="mock" class="org.mockito.Mockito">
 <beans:constructor-arg value="files.FileHandlingService"></beans:constructor-arg>
</beans:bean>

Once this mock bean is created, the behavior for the mock can be added in the @Before annotated method of junit, this way:

@Before
public void setUp() {
 when(fileHandlingServiceMock.handle((File)(anyObject()))).thenReturn("Completed File Processing");
}

@Test
public void testService() throws Exception{
 Message<?> message = this.testChannel.receive(5000);
 assertThat((String)message.getPayload(), equalTo("Completed File Processing"));
}

If the test is repeated now, surprisingly it will fail and the reason is - Spring application context is fully initialized by the time the call comes to the @Before method of Junit and the poller scanning the file coming into the folder gets triggered BEFORE the mock behavior is added on and so without the correct behavior of the mock service the test fails.

I am sure there are other fixes, but the fix that worked for me was to essentially control which folder is scanned and at what point the file is placed in the folder for the flow to be triggered. This is heavily based on some tests that I have seen in Spring Integration project itself. The trick is to create a temporary folder first using Spring config and set that folder as the polling folder:
<beans:bean id="temp" class="org.junit.rules.TemporaryFolder"
   init-method="create" destroy-method="delete"/>

<beans:bean id="inputDirectory" class="java.io.File">
 <beans:constructor-arg value="#{temp.newFolder('sitest').path}"/>
</beans:bean> 

<util:properties id="localProps">
 <beans:prop key="inbound.folder">#{inputDirectory.getAbsolutePath()}</beans:prop>
</util:properties>

Now place the file in the temporary folder only during the test run, this way @Before annotated method gets a chance to add behavior to the mock and the mocked behavior can be cleanly asserted:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("si-test.xml")
public class FileHandlingFlowTest {
 @Autowired @Qualifier("testChannel") private PollableChannel testChannel;
 @Autowired private FileHandlingService fileHandlingServiceMock;
 @Autowired @Qualifier("inputDirectory") private File inputDirectory;
 
 @Before
 public void setUp() {
  when(fileHandlingServiceMock.handle((File)(anyObject()))).thenReturn("Completed File Processing");
 }
 
 @Test
 public void testService() throws Exception{
  Files.copy(new File(this.getClass().getResource("/samplefolder/samplefile.txt").toURI()), new File(inputDirectory, "samplefile.txt"));
  Message<?> message = this.testChannel.receive(5000);
  assertThat((String)message.getPayload(), equalTo("Completed File Processing"));
 }
}

Sunday, April 28, 2013

Spring beans with same name and @Configuration

One of the important features when testing an application is being able to replace some of the real services with test doubles. With a Spring based application, this has typically been done by defining the test doubles with the same name as the original bean which is being mocked out and this works as the bean defined later is the one which is finally instantiated by the Spring container.

Consider a bean, call it memberService bean, having two implementations one defined using XML based bean definition files say in a context1.xml file:

<bean name="memberService" class="samples.config.MemberSvcImpl1"/>

and if a different implementation of memberService is needed for test, the way to do it would have been to define the bean with the same name, this way(say in a context2.xml file):

<import resource="context1.xml"/>
<bean name="memberService" class="samples.config.MemberSvcImpl2"/>

since the MemberSvcImpl2 is defined after MemberSvcImpl1, the MemberSvcImpl2 would be available for injection in tests.


However with @Configuration style of defining beans, things are not so clear cut. What does it mean to define a bean after another bean, consider the following which tries to mimic the definition in context2.xml file above:

@Configuration
@ImportResource("classpath:samples/config/context1.xml")
public class Context2Config {
 @Bean
 public MemberService memberService() {
  return new MemberSvcImpl2();
 }
}

Here the memberService defined in the @Configuration DOES NOT override the memberService bean defined in the xml. Something to be careful about.

The solution is actually simple - if you need to override a previously defined bean(without say the flexibility of autowiring with a different bean name), either use the XML bean configuration for both the bean being overridden and the overriding bean or use the @Configuration. XML bean configuration is the first example in this entry, the one with @Configuration would be something like this:

@Configuration
public class Context1JavaConfig {
 @Bean
 public MemberService memberService() {
  return new MemberSvcImpl1();
 }
}

@Configuration
@Import(Context1JavaConfig.class)
public class Context2JavaConfig {
 @Bean
 public MemberService memberService() {
  return new MemberSvcImpl2();
 }
}

This would work as expected. I am sure there are alternate ways of getting this to work, but the approach that I have outlined here has worked well for me and I have been sticking to this pattern

Friday, March 1, 2013

Test Fixtures - Using Spring scala

Continuing on my previous blog entry about creating test fixtures using Spring XML bean configuration file and the newer Spring @Configuration style, this time around I wanted to see how the same configuration turns out using the new Spring Scala project.

So this is what I had as a test fixture defined using xml bean configuration earlier:

<?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:p="http://www.springframework.org/schema/p"
 xmlns:c="http://www.springframework.org/schema/c"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

 <bean name="address1" class="el.Address" c:city="City1" c:state="State1"/>
 <bean name="address2" class="el.Address" p:city="City2" p:state="State2"/>
 <bean name="address3" class="el.Address" p:city="City3" p:state="State3"/>
 <bean name="address4" class="el.Address" p:city="City4" p:state="State4"/>
 <bean name="address5" class="el.Address" p:city="City5" p:state="State5"/>

 <bean name="member1" class="el.Member" c:first="First1" c:last="Last1" c:address-ref="address1"/>
 <bean name="member2" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address2"/>
 <bean name="member3" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address3"/>
 <bean name="member4" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address4"/>
 <bean name="member5" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address5"/>
 
</beans>

and using Java @Configuration:

@Configuration
public class FixturesJavaConfig {
 @Bean public Address address1(){return new Address("city1", "state1");}
 @Bean public Address address2(){return new Address("city2", "state2");}
 @Bean public Address address3(){return new Address("city3", "state3");}
 @Bean public Address address4(){return new Address("city4", "state4");}
 @Bean public Address address5(){return new Address("city5", "state5");}

 @Bean public Member member1(){return new Member("first1", "last1", address1());}
 @Bean public Member member2(){return new Member("first2", "last2", address1());}
 @Bean public Member member3(){return new Member("first3", "last3", address1());}
 @Bean public Member member4(){return new Member("first4", "last4", address1());}
 
 @Bean public Member member5(){
  Member member = new Member();
  member.setFirst("first5");
  member.setLast("last5");
  member.setAddress(address5());
  return member;
 }
}


Now, using Spring scala the bean configuration is the following:

import org.springframework.scala.context.function.FunctionalConfiguration

class MemberConfiguration extends FunctionalConfiguration {
  val address1 = bean() { new Address("city1", "state1") }
  val address2 = bean() { new Address("city2", "state2") }
  val address3 = bean() { new Address("city3", "state3") }
  val address4 = bean() { new Address("city4", "state4") }
  val address5 = bean() { new Address("city5", "state5") }

  bean("member1") { new Member("first1", "last1", address1()) }
  bean("member2") { new Member("first2", "last2", address2()) }
  bean("member3") { new Member("first3", "last3", address3()) }
  bean("member4") { new Member("first4", "last4", address4()) }
  bean("member5") {
    val member = new Member()
    member.setFirst("first5");
    member.setLast("last5");
    member.setAddress(address5());
    member
  }
}

The fixture configuration does look very clean and concise and I would definitely be looking out for the spring-scala project as it matures a little more - a few things which will need to be implemented are a way for bootstrapping this configuration with Spring based tests(through @ContextConfiguration), way to import this configuration into normal xml based bean configurations and into java based @Configurations.
For Scala only projects the Spring Scala project does look very promising.

Finally, this is a test for the "FunctionalConfiguration" above:

import org.scalatest.FunSuite
import org.springframework.scala.context.function.FunctionalConfigApplicationContext
import org.junit.runner.RunWith
import org.scalatest.junit.JUnitRunner
@RunWith(classOf[JUnitRunner])
class MemberConfigTest extends FunSuite {
  test("there should be 5 members in the configuration") {
    val applicationContext = new FunctionalConfigApplicationContext(classOf[MemberConfiguration])
    val members = applicationContext.getBeansOfType(classOf[Member])
    assert(members.size() === 5)
  }
}

Friday, February 22, 2013

Test fixtures - using XML Spring bean definition vs Java Configuration

Spring's Java based container configuration is a neat way of specifying Spring bean configurations and in my own projects I have systematically replaced XML configuration with Java Bean configuration where feasible.

However, there are still a few places where an XML bean configuration is a better fit than the Java Configuration, here I am focusing on one such use case.

Consider a test case which requires a fixture with a lot of test instances of domain classes, assume a simple domain of a Member(a person) with an address. This would be expressed the following way using a Spring XML configuration:

<?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:p="http://www.springframework.org/schema/p"
 xmlns:c="http://www.springframework.org/schema/c"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

 <bean name="member1" class="el.Member" c:first="First1" c:last="Last1" c:address-ref="address1"/>
 <bean name="member2" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address2"/>
 <bean name="member3" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address3"/>
 <bean name="member4" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address4"/>
 <bean name="member5" class="el.Member" p:first="First1" p:last="Last1" p:address-ref="address5"/>
 
 <bean name="address1" class="el.Address" c:city="City1" c:state="State1"/>
 <bean name="address2" class="el.Address" p:city="City2" p:state="State2"/>
 <bean name="address3" class="el.Address" p:city="City3" p:state="State3"/>
 <bean name="address4" class="el.Address" p:city="City4" p:state="State4"/>
 <bean name="address5" class="el.Address" p:city="City5" p:state="State5"/>
</beans>




The good thing about this configuration is that it is very easy to see the list of entities with Spring's c (constructor) and p(property) custom xml namespaces allowing a very concise expression.

On the other hand if the same fixture had been created through Java Configuration it would be a little more verbose, especially for cases where setters are used(like in member5 below):

@Configuration
public class FixturesJavaConfig {

 @Bean public Member member1(){return new Member("first1", "last1", address1());}
 @Bean public Member member2(){return new Member("first2", "last2", address1());}
 @Bean public Member member3(){return new Member("first3", "last3", address1());}
 @Bean public Member member4(){return new Member("first4", "last4", address1());}
 
 @Bean public Member member5(){
  Member member = new Member();
  member.setFirst("first5");
  member.setLast("last5");
  member.setAddress(address5());
  return member;
 }
 
 @Bean public Address address1(){return new Address("city1", "state1");}
 @Bean public Address address2(){return new Address("city2", "state2");}
 @Bean public Address address3(){return new Address("city3", "state3");}
 @Bean public Address address4(){return new Address("city4", "state4");}
 @Bean public Address address5(){return new Address("city5", "state5");}
}

A matter of choice at the end of the day I suppose, but this has become a pattern that I have been using now - use Java Configuration where feasible, but use XML configuration for cases where a bunch of test fixtures need to be created.

Thursday, February 7, 2013

Spring Bean names

Spring bean names are straightforward, except for cases where names are not explicitly specified.

To start with, Spring bean names for an xml based bean definition is specified this way:

<bean name="sampleService1" class="mvcsample.beanname.SampleService">
 <constructor-arg>
  <bean class="mvcsample.beanname.SampleDao"></bean>
 </constructor-arg>
</bean>

For a Java @Configuration based bean definition, the method name of the @Bean annotated method becomes the bean name:

@Configuration
@ComponentScan(basePackages="mvcsample.beanname")
public static class SpringConfig{
 
 @Bean
 public SampleService sampleService(){
  return new SampleService(sampleDao());
 }
 
 @Bean
 public SampleDao sampleDao(){
  return new SampleDao();
 }
 
}


and for Stereotype annotation(@Component, @Service, @Repository etc) based beans, the value field indicates the bean name:
@Repository("aSampleDao")
public class SampleDao {
    ...
}

@Service("aSampleService")
public class SampleService {
    ...
}

Now, what happens for cases where the bean name is not specified.

XML Based Bean Configuration Case:
For an xml based configuration, a case where the bean name is typically not specified are for beans which can act on the entire bean factory - say for eg, to define a BeanPostProcessor or a BeanFactoryPostProcessor
For eg. consider the following dummy BeanPostProcessor that just grabs all the bean names from bean factory:
public class BeanNameScanningBeanPostProcessor implements BeanPostProcessor{
 private List<String> beanNames = new ArrayList<>();
 @Override
 public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
  return bean;
 }

 @Override
 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
  beanNames.add(beanName);
  return bean;
 }
 
 public List<String> getBeanNames(){
  return this.beanNames;
 }
}

It would typically be defined in an xml bean configuration this way:
<bean class="mvcsample.beanname.BeanNameScanningBeanPostProcessor"/>

A second case with xml based configuration where a name is typically not specified is with inner beans, for eg. defined this way:
<bean class="mvcsample.beanname.SampleService">
 <constructor-arg>
  <bean class="mvcsample.beanname.SampleDao"></bean>
 </constructor-arg>
</bean>

The bean names for these cases is handled by a component called the BeanNameGenerator. For the case of a top level bean the name typically ends up being the package qualified class name along with a count of the instances, this way:

mvcsample.beanname.BeanNameScanningBeanPostProcessor#0

For the case of an inner bean, since it exists only in the scope of its containing bean, the name is not that relevant, however internally it does get a name based on the hex hash code of the bean definition for eg, "mvcsample.beanname.SampleDao#1881ee8b"


Java Based @Configuration Case:
For java based @Configuration on the other hand it is not possible to specify a bean without a name, the bean name is the method name.

Annotation based Configuration
For stereotype annotation based bean, if the name is not explicitly specified with the value field of stereotype annotations, then the name is again generated by AnnotationBeanNameGenerator which is an implementation of the BeanNameGenerator strategy interface, the names generated is simply the short name of the class, for eg from the javadoc for AnnotationBeanNameGenerator - bean name for com.xyz.FooServiceImpl becomes fooServiceImpl.

Conclusion:
So to finally conclude, if bean names are relevant to you in some way(for eg to disambiguate between multiple bean instances of same type), then it is best to be explicit about the names, otherwise depend on Spring to generate the bean names for you. In some cases, for eg. with Spring-data project it is possible to specify custom behavior for repositories as a separate bean and Spring-data by default uses Spring naming conventions to find the custom implementation and understanding how bean names are generated helps.


Friday, February 1, 2013

atan2 in scala

atan2 function is defined as follows:



I wanted to try a small exercise of implementing this using scala(ignoring the fact that it is already natively implemented in java.lang.Math library).

The simplest implementation that I could think of is with a if expression this way:


def atan2(x: Double, y: Double):Double = {
  if (x >0)                     atan(y/x)
  else if (y >= 0 && x < 0)     Pi + atan(y/x)
  else if (y < 0 && x < 0)      atan(y/x) - Pi
  else if (y > 0 && x==0)       Pi/2
  else if (y < 0 && x==0)       -Pi/2
  else                          Double.NaN
}

However, I wanted to see at this point if it could be reimplemented using a case-match expression, and I could only come up with a souped up version of if/else this way:

def atan2(x: Double, y: Double): Double = {
  true match {
    case _ if (x>0)             => atan(y/x)
    case _ if (y >= 0 && x < 0) => atan(y/x) + Pi
    case _ if (y < 0 && x < 0)  => atan(y/x) - Pi
    case _ if (y > 0 && x==0)   => Pi/2
    case _ if (y <0 && x==0)    => -Pi/2
    case _                      => Double.NaN
  }
}

After reading up a little more on scala extractors, I could come up with a crazier version of the same:
def atan2(x: Double, y: Double): Double = {
  (x, y) match {
    case xgt0()           => atan(y/x)
    case ygte0Andxlt0()   => atan(y/x) + Pi
    case ylt0Andxlt0()    => atan(y/x) - Pi
    case ygt0Andxeq0()    => Pi/2
    case ylt0Andxeq0()    => -Pi/2
    case _                => Double.NaN
  }
}

However, this unfortunately requires defining 5 extractors this way:
object xgt0 {
 def unapply(tup: (Double, Double)): Boolean = tup match { case (x,y) => (x>0)}
}

object ygte0Andxlt0 {
 def unapply(tup: (Double, Double)): Boolean = tup match { case (x, y) => (y >= 0 && x < 0)}
}

object ylt0Andxlt0 {
 def unapply(tup: (Double, Double)): Boolean = tup match { case (x, y) => (y < 0 && x < 0)}
}
 
object ygt0Andxeq0 {
 def unapply(tup: (Double, Double)): Boolean = tup match { case (x, y) => (y > 0 && x == 0)}
}

object ylt0Andxeq0 {
 def unapply(tup: (Double, Double)): Boolean = tup match { case (x, y) => (y < 0 && x == 0)}
}

The only conclusion I could make out of this is that if I had to re-write atan2 in scala the best approach is probably using the first one - using if expression. I am sure there is definitely a more scala way of doing this and would definitely appreciate any suggestions on these approaches

Wednesday, January 30, 2013

CGLIB and ASM inlined with Spring 3.2

This is a small change, but will go some way with issues that I have faced in the past in getting the correct dependency of CGLIB/ASM with my projects. CGLIB and its dependency ASM are now both inlined with the Spring-Core binaries(as of Spring 3.2+) - their source is not maintained with the spring-core project, but are inlined at build time. From the maven pom.xml perspective, the following can now be kept out of the file:

<dependency>
 <groupId>cglib</groupId>
 <artifactId>cglib</artifactId>
 <version>2.2.2</version>
</dependency>

Thursday, January 24, 2013

Aspectj pointcut expression based on annotation on types/methods

Consider two classes, one with annotation applied on the type and one with annotation on a method:

@CustomAnnotation
public class Class1 {
 
 public void method11(){}

 public void method12(){}
}

public class Class2 {
 
 @CustomAnnotation
 public void method21(){}
 
 public void method22(){}

}


I had to write a Aspectj pointcut which selects the methods on classes where the CustomAnnotation is applied on types - methods of Class1 above. My first gut feel was to write an aspect along these lines:
@Pointcut("execution(@CustomAnnotation  * *.*(..))")
public void methodsInAnnotatedTypes(){}

This pointcut is wrong though, as it ends up selecting methods of Class2.

The reason is this, the pointcut expression signature for execution pointcut type is the following(this is from the Spring documentation site available here):

execution(modifiers-pattern? ret-type-pattern declaring-type-pattern?.name-pattern(param-pattern) throws-pattern?)

To select the methods based on annotation on the type, I have to add the annotation to the declaring-type-pattern above like the following:

execution(modifiers-pattern? ret-type-pattern (@CustomAnnotation declaring-type-pattern?).name-pattern(param-pattern) throws-pattern?)

Having it in the beginning will select any methods with Custom annotation on the method:
execution(@CustomAnnotation modifiers-pattern? ret-type-pattern declaring-type-pattern?.name-pattern(param-pattern) throws-pattern?)

So with this fix the correct pointcut expression becomes, and this selects the methods of Class1:

@Pointcut("execution(* (@CustomAnnotation *).*(..))")
public void methodsInAnnotatedTypes(){
 
}


Saturday, January 19, 2013

Mixin in Java with Aspects - for a Scala traits sample

Scala traits allow new behaviors to be mixed into a class.

Consider two traits to add auditing and version related fields to JPA entities:

package mvcsample.domain

import javax.persistence.Version
import scala.reflect.BeanProperty
import java.util.Date

trait Versionable {
  @Version
  @BeanProperty
  var version: Int = _
}

trait Auditable {
  @BeanProperty
  var createdAt: Date = _
 
  @BeanProperty
  var updatedAt: Date = _
}

Now to mix in 'Versionable' and 'Auditable' with their fields and behavior in a Member entity:

@Entity
@Table(name = "members")
class Member(f: String, l: String) extends BaseDomain with Auditable with Versionable {

  def this() = this(null, null)

  @BeanProperty
  var first: String = f

  @BeanProperty
  var last: String = l

  @OneToMany(fetch = FetchType.EAGER, mappedBy = "member")
  @BeanProperty
  var addresses: java.util.List[Address] = _
}

trait BaseDomain {
  @BeanProperty
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "id")
  @Id
  var id: Long = 0
}


The Member class above will now have the behavior of the BaseDomain class, and will have the behavior of Versionable trait and the Auditable trait.

This kind of mixin is not possible with plain Java, as the equivalent of traits with fields and behavior would be an abstract(or concrete) class and Java allows deriving only from 1 base class. However with AspectJ it is possible to achieve an equivalent of mixin.

Consider the following aspects defined using Aspectj language:
package mvcsample.aspect;

import javax.persistence.Column;
import javax.persistence.Version;
import mvcsample.annot.Versioned;

public interface Versionable {
    
    static aspect VersionableAspect {
        declare parents: @Versioned  mvcsample.domain.* implements Versionable;
        
        @Version
        @Column(name = "version")
        private Integer Versionable.version;    
        
        public Integer Versionable.getVersion() {
        return this.version;
            }
        
        public void Versionable.setVersion(Integer version) { 
        this.version = version;
        }
    }
}


package mvcsample.aspect;

import java.util.Date;
import javax.persistence.Column;

import mvcsample.annot.Audited;
public interface Auditable {
    static aspect AuditableAspect {
        declare parents: @Audited mvcsample.domain.* implements Auditable ;
    
        @Column(name="created_at")
        private Date Auditable.createdAt;
        
        @Column(name="updated_at")
        private Date Auditable.updatedAt;
        
        public Date Auditable.getCreatedAt(){
            return this.createdAt;
        }
        
        public void Auditable.setCreatedAt(Date createdAt) {
            this.createdAt = createdAt;
        }
        
        public Date Auditable.getUpdatedAt(){
            return this.updatedAt;
        }
        
        public void Auditable.setUpdatedAt(Date updatedAt) {
            this.updatedAt = updatedAt;
        }
    }
}

"declare parents: @Versioned mvcsample.domain.* implements Versionable;" aspectj construct adds 'Versionable' interface as a parent to any class in package 'mvcsampple.domain' annotated with @Versioned, similarly the one for 'Auditable'
Then the aspect goes about adding fields to the Versionable interface which in turn ends up adding(mixing in) the fields to the targeted entity classes, this way the Audit related and Version related fields and methods get mixed into the entity classes.

With these two aspects defined, a target entity class would look like this:
@Entity
@Table(name="members")
@Access(AccessType.FIELD)
@Versioned
@Audited
public class Member extends BaseDomain{
 
 public Member(){}
 
 public Member(String first, String last){
  this.first = first;
  this.last = last;
 }
 
 private String first;
 
 @Size(min=1)
 private String last;
 
 @OneToMany(fetch=FetchType.EAGER, mappedBy="member")
 private List<Address> addresses = new ArrayList<>();
 
    ...
}


The fields and behavior defined in the Versionable and Auditable aspects would be mixed into this entity(more generally into any entity with @Versioned and @Audited annotations)

Probably not as clean as Scala traits but works nicely.