Support specifying TimeZone in Jackson2ObjectMapperFactoryBean [SPR-12594]

[spring-projects-issues]

Eric Rizzo opened SPR-12594 and commented

Jackson2ObjectMapperFactoryBean should expose the timeZone property of ObjectMapper, to allow easily specifying a TimeZone to be used when parsing "plain" dates. Currently this can be done by extending Jackson2ObjectMapperFactoryBean and setting the ObjectMapper.setTimeZone() as it is being built, but that's awkward.
In general, Jackson2ObjectMapperFactoryBean should be consistent and expose all properties of ObjectMapper that an application might want to set.

---

Affects: 4.1.3

Issue Links:

• Allow Jackson2ObjectMapperBuilder configuration to override the well-known modules' configuration [SPR-12634] #17235 Allow Jackson2ObjectMapperBuilder configuration to override the well-known modules' configuration

Referenced from: commits 77fcf21, fab8dd3, bf7a975, b89e62e

[spring-projects-issues]

Juergen Hoeller commented

Specifically with the time zone setting, we should try to integrate it with the time zone management in Spring MVC, that is, the thread-local time zone - and only fall back to a globally configured time zone, analogous to our formatters. So this should probably be a 4.2-only change.

Juergen

[spring-projects-issues]

Eric Rizzo commented

While I understand the desire to align this with Spring MVC's timezone capability in 4.2, I don't understand why the 4.1 stream can't have this less-capable version rather than nothing at all. Not every app is going to wait for or update to 4.2 right away; seems like this is still better than nothing for those of us who need it right away and/or will be stuck on 4.1 for a while. Is there something in the Spring MVC stuff that makes it incompatible with this simple idea?

[spring-projects-issues]

Juergen Hoeller commented

Alright, I don't mind it staying on the 4.1.x agenda. However, let's nevertheless consider the thread-local time zone scenario upfront and possibly implement it in 4.1.x as well.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

If I follow Jackson's documentation right, it seems to default to GMT and not to the system time zone for JSON date processing. So Jackson's time zone setting seems to be more of an application-wide convention for JSON parsing, independent from general system configuration and custom user interface settings. The locale property on ObjectMapper seems to be used for date processing as well, for similar purposes, so configuring it at the ObjectMapper level seems to be alright too - even if it looks a bit strange.

In contrast to that, the request-specific locale and time zone in Spring MVC is primarily a user interface setting. It seems like this doesn't fit here to begin with, since the JSON part of an application might rather want to consistently process dates in a configured time zone - and not allow the user to choose a specific date format per request like we do for user interfaces. As a consequence, let's not bother with specific MVC integration there yet (unless explicitly requested with a good use case at some later point).

In summary, straightforward locale and time zone properties on Jackson2ObjectMapperFactoryBean seem to be fine at this point. Let's implement it that way for 4.2 and 4.1.5.

Juergen

[spring-projects-issues]

Sébastien Deleuze commented

Resolved on master by this commit + this one (I unintentionally used a Java 8 class in the first commit), ready to be backported on the 4.1.x branch.

[spring-projects-issues]

Juergen Hoeller commented

A bit of fine-tuning during the backport, to be applied to master as well:

• Jackson2ObjectMapperFactoryBean doesn't have an overloaded setTimeZone method anymore, since that might lead to JavaBeans introspection issues. There's no need for a String-based version anyway since there's always a TimeZone converter registered in the container.

• Jackson2ObjectMapperBuilder.timeZone(String) uses our StringUtils.parseTimeZoneString, which doesn't expose the undesirable GMT fallback in case of invalid Strings but rather throws an IllegalArgumentException now, like our TimeZone conversion in other places.

• Jackson2ObjectMapperBuilder has a locale(String) variant now, analogous to timeZone(String), delegating to StringUtils.parseLocaleString.