Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying TimeZone in Jackson2ObjectMapperFactoryBean [SPR-12594] #17195

Closed
spring-issuemaster opened this issue Jan 2, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jan 2, 2015

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:

  • #17235 Allow Jackson2ObjectMapperBuilder configuration to override the well-known modules' configuration

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 10, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 12, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 11, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.