Friday, January 17, 2014

Consuming Spring-hateoas Rest service using Spring RestTemplate and Super type tokens

Spring-hateoas provides an excellent way for applications to create REST based services which follow the HATEOAS principle.

My objective here is not to show how to create the service itself, but to demonstrate how to write a client to the service.

The sample service that I am going to use is the "the-spring-rest-stack" written by Josh Long(@starbuxman). The specific subproject that I am going to use is the hateoas one here. If this subproject is run using "mvn jetty" command, a REST based endpoint to list the details of a user is available at http://localhost:8080/users/2 where "2" is the id of the user and gives a result of the following structure:

{
    "links": [{
        "rel": "self",
        "href": "http://localhost:8080/users/2"
    }, {
        "rel": "customers",
        "href": "http://localhost:8080/users/2/customers"
    }, {
        "rel": "photo",
        "href": "http://localhost:8080/users/2/photo"
    }],
    "id": 2,
    "firstName": "Lois",
    "profilePhotoMediaType": null,
    "lastName": "Lane",
    "username": "loislane",
    "password": null,
    "profilePhotoImported": false,
    "enabled": true,
    "signupDate": 1370201631000
}

To get to a specific customer of this user, the endpoint is at http://localhost:8080/users/2/customers/17, which gives an output of the following structure:

{
    "links": [{
        "rel": "self",
        "href": "http://localhost:8080/users/2/customers/17"
    }, {
        "rel": "user",
        "href": "http://localhost:8080/users/2"
    }],
    "id": 17,
    "signupDate": 1372461079000,
    "firstName": "Scott",
    "lastName": "Andrews",
    "databaseId": 17
}


Now for a consumer of these two services, the result can be represented by a java type called Resource in the Spring-hateoas project and is a generic class with the following signature:

public class Resource<T> extends ResourceSupport {

 protected Resource() {
  this.content = null;
 }

 public Resource(T content, Link... links) {
  this(content, Arrays.asList(links));
 }

...


So the consumer of the above two services will get back the following two types:

Resource<User> user = .... //call to the service

Resource<Customer> customer = ... //call to the service

The issue now is that since the "user" and "customer" above are parameterized types, if I were to bind the types using Jackson as the json processor, I would be doing something along the following lines:

ObjectMapper objectMapper = new ObjectMapper();
Resource<Customer> customer = objectMapper.readValue(customerAsJson, Resource.class);
Resource<User> user = objectMapper.readValue(userAsJson, Resource.class);

The above will not work however, the reason is because of the lost type information of the parameterized Resource due to Java type erasure, Jackson wouldn't know to create an instance of Resource<User> or Resource<Customer>

The fix is to use a Super Type Token, which is essentially a way to provide the type information for libraries like Jackson and I have blogged about it before here. With this, a working code to map the json to the appropriate parameterized type would look like this:

ObjectMapper objectMapper = new ObjectMapper();
Resource<Customer> customer = objectMapper.readValue(customerAsJson, new TypeReference<Resource<Customer>>() {});
Resource<User> customer = objectMapper.readValue(userAsJson, new TypeReference<Resource<User>>() {});

Spring's client abstraction to deal with Rest based services is RestTemplate, and this can deal with a variety of message formats(xml, json, atom etc) using an abstraction called HttpMessageConverter to deal with the specifics of binding for each of the message formats.

Spring RestTemplate provides its own implementation of Super Type token to be able to bind different message formats to parameterized types, along the lines of Jackson's TypeReference, it is called the ParameterizedTypeReference.

ParameterizedTypeReference can be used to cleanly bind Rest responses for User and Customer to Java types this way:

RestTemplate restTemplate = new RestTemplate();
ResponseEntity<Resource<User>> responseEntity =
  restTemplate.exchange("http://localhost:8080/users/2", HttpMethod.GET, null, new ParameterizedTypeReference<Resource<User>>() {}, Collections.emptyMap());
if (responseEntity.getStatusCode() == HttpStatus.OK) {
 Resource<User> userResource = responseEntity.getBody();
 User user = userResource.getContent();
}

RestTemplate restTemplate = new RestTemplate();
ResponseEntity<Resource<Customer>> responseEntity =
  restTemplate.exchange("http://localhost:8080/users/2/customers/17", HttpMethod.GET, null, new ParameterizedTypeReference<Resource<Customer>>() {}, Collections.emptyMap());
if (responseEntity.getStatusCode() == HttpStatus.OK) {
 Resource<Customer> customerResource = responseEntity.getBody();
 Customer customer = customerResource.getContent();
}

In conclusion, ParameterizedTypeReference provides a neat way of dealing with the parameterized types and is incredibly useful in consuming the Spring Hateoas based REST services.

Thursday, January 9, 2014

Spring Integration Publisher

Consider a hypothetical requirement - You have a service class in your application and you want to capture some information around the calls to this service:

@Service
public class SampleBean {
 private static final Logger logger = LoggerFactory.getLogger(SampleBean.class);

 public Response call(Request request) {
  logger.info("SampleBean.call invoked");
  return new Response(true);
 }
}

AOP is a great fit for such a requirement, it allows the information around a method call(a pointcut) to be cleanly captured and some processing(an advice) to be done with this information:

public class AuditAspect {
 private static final Logger logger = LoggerFactory.getLogger(AuditAspect.class);
 @Pointcut("execution( * core.SampleBean.call(model.Request)) && args(r)")
 public void beanCalls(Request r){}

 @Around("beanCalls(r)")
 public Object auditCalls(ProceedingJoinPoint pjp, Request r) {
     logger.info("Capturing request: " + r);
  try{
   Object response = pjp.proceed();
   logger.info("Capturing response: " + response);
   return response;
  }catch(Throwable e) {
   throw new RuntimeException(e);
  }
 }
}


This appears to be good enough. Now what if I wanted to return the response back to the client immediately but continue to process the context of the method call - well we can place the logic of Advice in a separate thread using a ThreadPool. Let me add another layer of complexity now, what if we wanted to absolutely ensure that context is not lost - a good way to do this would be to keep the context of the method call outside the JVM, typically messaging providers like RabbitMQ and ActiveMQ will fit in very well.


Considering these additional requirements, a simpler solution especially with messaging scenarios coming into play will be to use Spring Integration. Let us start by defining a new Spring Integration application context:

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
    xmlns:beans="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration.xsd
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <annotation-config/>

    <channel id="tobeprocessedlater"/>

    <logging-channel-adapter channel="tobeprocessedlater" log-full-message="true"/>

</beans:beans>

It just has the definition of a channel, and an outbound adapter which reads from this channel and logs the full message. To capture the context of the call to the SampleBean a Publisher annotation can be added to the relevant methods of SampleBean which will direct "stuff" to the channel which is added to the annotation.

@Service
public class SampleBean {
 private static final Logger logger = LoggerFactory.getLogger(SampleBean.class);

 @Publisher(channel = "tobeprocessedlater")
 public Response call(@Header("request") Request request) {
  logger.info("SampleBean.call invoked");
  return new Response(true);
 }
}

what "stuff" is sent to this "tobeprocessedlater" channel is specified through additional annotations - by default the return value from the method is sent to the channel, additionally I have tagged the request also with the @Header annotation, this will make the request to be sent in as a header to the response message. Just for completeness, the integration context has a <annotation-config/> tag, this tag registers the relevant components that look for @Publisher annotation and weave in the additional action to be performed if it finds one.

If this code is executed now, the output will be along these lines:

                       core.SampleBean - SampleBean.call invoked
o.s.integration.handler.LoggingHandler - [Payload=Response{success=true}][Headers={request=RequestType1{attr='null'}, id=52997b10-dc8e-e0eb-a82a-88c1df68fca5, timestamp=1389268390212}]

Now, to layer in the first requirement, to handle the advice(in this case the logging) in a separate thread of execution:

This can be done with just a configuration change! - instead of publishing the message to a direct channel, publish it to a channel type that can buffer messages or use an executor to dispatch messages, I have opted to use an executor channel in this example:

    <channel id="tobeprocessedlater">
        <dispatcher task-executor="taskExecutor"/>
    </channel>

Now to add the requirement to make the async message processing a little more reliable by publishing it to an external Messaging provider(and processing the messages later), let me demonstrate this by publishing the messages to RabbitMQ, the code change again is pure configuration and nothing in the code changes!:

    <channel id="tobeprocessedlater"/>

    <int-amqp:outbound-channel-adapter amqp-template="amqpTemplate" channel="tobeprocessedlater"  />

The messaging sink could have been anything - a database, a file system, ActiveMQ, and the change that would have been required is pure configuration.

Wednesday, January 1, 2014

Objenesis for class instantiation

Objenesis is a neat little library for instantiating classes . Consider the following class:

public class Person {
    private final String firstName;
    private final String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
    ...
}    

If the structure of the class and its constructor is known, then a framework can instantiate this class purely using reflection:

Constructor<Person> ctor = Person.class.getDeclaredConstructor(String.class, String.class);
Person personThroughCtor = ctor.newInstance("FirstName", "LastName");


However, if the constructor structure is not known ahead of time, creating the class instance is not easy, for eg the following will throw an exception:

Constructor<Person> ctor = Person.class.getDeclaredConstructor();
Person personThroughCtor = ctor.newInstance("FirstName", "LastName");

Exception:

java.lang.NoSuchMethodException: mvcsample.obj.Person.<init>()
 at java.lang.Class.getConstructor0(Class.java:2810)
 at java.lang.Class.getDeclaredConstructor(Class.java:2053)


Objenesis provides the solution here, of being able to instantiate an instance of Person class without needing to call its constructor:

Objenesis objenesis = new ObjenesisStd(true);
ObjectInstantiator personInstantiator = objenesis.getInstantiatorOf(Person.class);

Person person = (Person)personInstantiator.newInstance();

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();
}