DDevelopment & Design

Formatting Java Time with Spring Boot using JSON

stf0-banner The aim of this post is to summarize and review ways of formatting Java Time objects using Spring Boot and Jackson library.

This post is organized into five steps. Each step represents one aspect of the issue and it is also related to one commit in the example project repository.

Step 0 – Prerequirements

Versions and dependencies

This tutorial is based on Spring Boot version 1.3.1.RELEASE with spring-boot-starter-web. It uses jackson-datatype-jsr310 from com.fasterxml.jackson.datatype in version 2.6.4, which is a default version of Spring Boot. All of these is based on Java 8.

The Code

In the example code repository, you can find one HTTP service made with Spring Boot. This service is a GET operation, which returns a class with Java Time objects. You can also find the integration test that deserializes the response.

Step 1 – The goal

I would like to return class Clock, containing LocalDate,LocalTime and LocalDateTime, preinitialized in constructor.

public final class Clock {
    private final LocalDate localDate;
    private final LocalTime localTime;
    private final LocalDateTime localDateTime;
    ...
}

Response class is serialized to JSON Map, which is a default behaviour. To some extent it is correct, but ISO-formatted Strings in response are preferable.

{  
    "localDate":{  
        "year":2016,
        "month":"JANUARY",
        "era":"CE",
        "dayOfYear":1,
        "dayOfWeek":"FRIDAY",
        "leapYear":true,
        "dayOfMonth":1,
        "monthValue":1,
        "chronology":{  
            "id":"ISO",
            "calendarType":"iso8601"
        }
    }
}

Integration testing is an appropriate way to test our functionality.

ResponseEntity resp = sut.getForEntity("http://localhost:8080/clock", Clock.class);

assertEquals(OK, resp.getStatusCode());
assertEquals(c.getLocalDate(), resp.getBody().getLocalDate());
assertEquals(c.getLocalTime(), resp.getBody().getLocalTime());
assertEquals(c.getLocalDateTime(), resp.getBody().getLocalDateTime());

Unfortunately, tests are not passing, because of deserialization problems. The exception with message is thrown can not instantiate from JSON object.

Step 2 – Adds serialization

First things first. We have to add JSR-310 module. It is a datatype module to make Jackson recognize Java 8 Date & Time API data types.

Note that in this example jackson-datatype-jsr310 version is inherited from spring-boot-dependencies dependency management.

com.fasterxml.jackson.datatype
      jackson-datatype-jsr310

Response is now consistent but still, not perfect. Dates are serialized as numbers:

{  
    "version":2,
    "localDate":[  
        2016,
        1,
        1
    ],
    "localTime":[  
        10,
        24
    ],
    "localDateTime":[  
        2016,
        1,
        1,
        10,
        24
    ],
    "zonedDateTime":1451640240.000000000
}

We are one step closer to our goal. Tests are passing now because this format can be deserialized without any additional deserializers. How do I know? Start an application server on commit Step 2 - Adds Object Mapper, then checkout to Step 1 - Introduce types and problems, and run integration tests without @WebIntegrationTest annotation.

Step 3 – Enables ISO formatting

ISO 8601 formatting is a standard. I’ve found it in many projects. We are going to enable and use it. Edit spring boot properties file application.properties and add the following line:

spring.jackson.serialization.WRITE_DATES_AS_TIMESTAMPS = false

Now, the response is something that I’ve expected:

{  
    "version":2,
    "localDate":"2016-01-01",
    "localTime":"10:24",
    "localDateTime":"2016-01-01T10:24",
    "zonedDateTime":"2016-01-01T10:24:00+01:00"
}

Step 4 – Adds on-demand formatting pattern

Imagine one of your client systems does not have the capability of formatting time. It may be a primitive device or microservice that treats this date as a collection of characters. That is why special formatting is required.

We can change formatting in response class by adding JsonFormat annotation with pattern parameter. Standard SimpleDateFormat rules apply.

@JsonFormat(pattern = "dd::MM::yyyy")
private final LocalDate localDate;
    
@JsonFormat(pattern = "KK:mm a")
private final LocalTime localTime;

Below there is a service response using custom @JsonFormat pattern:

{  
    "version":2,
    "localDate":"01::01::2016",
    "localTime":"10:24 AM",
    "localDateTime":"2016-01-01T10:24",
    "zonedDateTime":"2016-01-01T10:24:00+01:00"
}

Our tests are still passing. It means that this pattern is used for serialization in service and deserialization in tests.

Step 5 – Globally changes formatting

There are situations where you have to resign from ISO 8601 formatting in your whole application, and apply custom-made standards.

In this part, we will redefine the format pattern for LocalDate. This will change formatting of LocalDate in every endpoint of your API.

We have to define: – DateTimeFormatter with our pattern. – Serializer using defined pattern. – Deserializer using defined pattern. – ObjectMapper bean with custom serializer and deserializer. – RestTemplate that uses our ObjectMapper.

Bean ObjectMapper is defined with annotation @Primary, to override default configuration. My custom pattern for LocalDate is dd::MM::yyyy

public static final DateTimeFormatter FORMATTER = ofPattern("dd::MM::yyyy");
    
@Bean
@Primary
public ObjectMapper serializingObjectMapper() {
    ObjectMapper objectMapper = new ObjectMapper();
    JavaTimeModule javaTimeModule = new JavaTimeModule();
    javaTimeModule.addSerializer(LocalDate.class, new LocalDateSerializer());
    javaTimeModule.addDeserializer(LocalDate.class, new LocalDateDeserializer());
    objectMapper.registerModule(javaTimeModule);
    return objectMapper;
}

Definitions of serializer and deserializer for all LocalDate classes:

public class LocalDateSerializer extends JsonSerializer {
    
    @Override
    public void serialize(LocalDate value, JsonGenerator gen, SerializerProvider serializers) throws IOException {
        gen.writeString(value.format(FORMATTER));
    }
}
    
public class LocalDateDeserializer extends JsonDeserializer {
    
    @Override
    public LocalDate deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
        return LocalDate.parse(p.getValueAsString(), FORMATTER);
    }
}

Now, the response is formatted with our custom pattern:

{  
    "localDate":"01::01::2016"
}

Tests

When we define a custom serializer, our tests start to fail. It is because RestTemplate knows nothing about our deserializer. We have to create a custom RestTemplateFactory that creates RestTemplate with object mapper containing our deserializer.

@Configuration
public class RestTemplateFactory {
    
    @Autowired
    private ObjectMapper objectMapper;
    
    @Bean
    public RestTemplate createRestTemplate() {
        RestTemplate restTemplate = new RestTemplate();
        List converters = new ArrayList();
        MappingJackson2HttpMessageConverter jsonConverter = new MappingJackson2HttpMessageConverter();
        jsonConverter.setObjectMapper(objectMapper);
        converters.add(jsonConverter);
        restTemplate.setMessageConverters(converters);
        return restTemplate;
    }
}

Conclusion

Custom formatting Dates is relatively simple, but you have to know how to set up it. Luckily, Jackson works smoothly with Spring. If you know other ways of solving this problem or you have other observations, please comment or let me know.

Blog from Michał Lewandowski personal blog. Photo Credit.

— Previous article

Clojure - Fascinated, Disappointed, Astonished

Next article —

HAProxy load balancing with sticky sessions based on request body

You May Also Like
DDevelopment & Design

Log4j and MDC in Grails

Log4j provides very useful feature: MDC - mapped diagnostic context. It can be used to store data in context of current thread. It may sound scary a bit but idea is simple.

My post is based on post http://burtbeckwith.com/blog/?p=521 from Burt Beckwith's excellent blog, it's definitely worth checking if you are interested in Grails.

Short background story...


Suppose we want to do logging our brand new shopping system and we want to have in each log customer's shopping basket number. And our system can be used at once by many users who can perform many transactions, actions like adding items and so on. How can we achieve that? Of course we can add basket number in every place where we do some logging but this task would be boring and error-prone. 

Instead of this we can use MDC to store variable with basket number in map. 

In fact MDC can be treated as map of custom values for current thread that can be used by logger. 


How to do that with Grails?


Using MDC with Grails is quite simple. All we need to do is to create our own custom filter which works for given urls and puts our data in MDC.

Filters in Grails are classes in directory grails-app/conf/* which names end with *Filters.groovy postfix. We can create this class manually or use Grails command: 
grails create-filters info.rnowak.App.Basket

In result class named BasketFilters will be created in grails-app/conf/info/rnowak/UberApp.

Initially filter class looks a little bit empty:
class BasketFilters {
    def filters = {
        all(controller:'*', action:'*') {
            before = {

            }
            after = { Map model ->

            }
            afterView = { Exception e ->

            }
        }
    }
}
All we need to do is fill empty closures, modify filter properties and put some data into MDC.

all is the general name of our filter, as class BasketFilters (plural!) can contain many various filters. You can name it whatever you want, for this post let assume it will be named basketFilter. 

Another thing is change of filter parameters. According to official documentation (link) we can customize our filter in many ways. You can specify controller to be filtered, its actions, filtered urls and so on. In our example you can stay with default option where filter is applied to every action of every controller. If you are interested in filtering only some urls, use uri parameter with expression describing desired urls to be filtered.

Three closures that are already defined in template have their function and they are started in these conditions:

  • before - as name says, it is executed before filtered action takes place
  • after - similarly, it is called after the action
  • afterView - called after rendering of the actions view
Ok, so now we know what are these mysterious methods and when they are called. But what can be done within them? In official Grails docs (link again) under section 7.6.3 there is a list of properties that are available to use in filter.

With that knowledge, we can proceed to implementing filter.

Putting something into MDC in filter


What we want to do is quite easy: we want to retrieve basket number from parameters and put it into MDC in our filter:
class BasketFilters {
    def filters = {
        basketFilter(controller:'*', action:'*') {
            before = {
                MDC.put("basketNumber", params.basketNumber ?: "")
            }
            after = { Map model ->
                MDC.remove("basketNumber")
            }
        }
    }
}

We retrieve basket number from Grails params map and then we put in map under specified key ("basketNumber" in this case), which will be later used in logger conversion pattern. It is important to remove custom value after processing of action to avoid leaks.

So we are putting something into MDC. But how make use of it in logs?


We can refer to custom data in MDC in conversion patter using syntax: %X{key}, where key is our key we used in filter to put data, like:
def conversionPattern = "%d{yyyy-MM-dd HH:mm:ss} %-5p %t [%c{1}] %X{basketNumber} - %m%n"


And that's it :) We've put custom data in log4j MDC and successfully used it in logs to display interesting values.