Don't register JodaModule with Jackson ObjectMapper

[Stefan Weber]

Hi,

I don't want to use the JodaModule in the ObjectMapper but it seems impossible to avoid that as it's registered in the constructor of ObjectMapperFactory. Currently I can use reflection to delete the module but that's not a very satisfactory solution. Is there a better way to achieve the same goal?

Thanks,

Stefan

[Nick Telford]

I can't think of any. Why do you not want the JodaModule?

[Stefan Weber]

The LocalDateSerializer uses too strict a parser (i.e. DateTimeFormatter) for my purposes. It uses ISODateTimeFormat.date(), which expects a date like yyyy-MM-dd. However, what I often get in JSON requests from the client side is something of the form yyyy-MM-dd'T'hh:mm:ssZ (because it's a JavaScript client and the JavaScript Date object always seems to include the time portion). So what I want is a formatter/parser that optionally allows the  'T'hh:mm:ssZ part.

Here is the formatter I am using to achieve this:

new DateTimeFormatterBuilder()

                .append(ISODateTimeFormat.date())

                .appendOptional(ISODateTimeFormat.tTime().getParser())

                .toFormatter();

And because I can't change the parser in the LocalDateSerializer I had to roll my own deserializer that I register with the ObjectFactory.

[Nick Telford]

I think you mean LocalDateDeserializer?

Can you not deserialize to a LocalDateTime, and call LocalDateTime#toLocalDate() ?

[Tatu Saloranta]

Could you consider possibility of helping improve Joda module here?

I can help integrating the fix, and I suspect others would be interested in getting handling improved.

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stefan Weber]

Yes, I mean LocalDateDeserializer, sorry.

That would work. But then I would need to change the types of my model objects just to get the parsing working. In the interest of readability I want the types to communicate as much as possible--and it does not make sense for the properties in question to have a time portion.

[Stefan Weber]

I'm happy to do that.

But I think the desired semantics are use case specific--it can make perfect sense for the LocalDateDeserializer to fail if the string has a time portion. So ultimately, I think there needs to be a way to configure the parsers in JodaModule. Does that make sense?

And once that's done, also Dropwizard would need to change the way it configures the ObjectMapper. One needs to be able to pass a JodaModule with the properly configured parsers (but currently Dropwizard instantiates JodaModule internally)

[Tatu Saloranta]

On Thu, Nov 21, 2013 at 2:27 AM, Stefan Weber <stefan...@gmail.com> wrote:

I'm happy to do that.

But I think the desired semantics are use case specific--it can make perfect sense for the LocalDateDeserializer to fail if the string has a time portion. So ultimately, I think there needs to be a way to configure the parsers in JodaModule. Does that make sense?

Yes. Although my implied question is "does anyone actually need stricter definition" -- I have learnt to wait for actual need for configurable handling, since otherwise it is easy to implement things that are not really needed.

I don't feel strongly either way, just note that perhaps we could simply relax the checks without further need for configurability.

But adding configurability for Joda module could be easy; about the only challenge is that settings need to be somewhat static, there is no good way to change settings on per-call basis.

This should not be a problem here.

So one possiblity would be to add something like `enum JodaFeatures`, similar to existing on/off features for other things. I can help with that.

-+ Tatu +-

[Johan Wirde]

I have similar problems with FuzzyEnumModule (it causes me problems, but there is no easy way to exclude it). Would be great to have some control over how ObjectMapper is instantiated!

[Christer Sandberg]

The FuzzyEnumModule is a show stopper for us as well. We have @JsonCreator annotated factory methods for our enums and this module breaks that.

We can't update to 0.7.0 until there's a way of choosing whether to include Jackson modules or not.

[Tatu Saloranta]

One minor thing that might be helpful here would be to improve FuzzyEnumModule to check for existence of @JsonCreator, and skip use of custom one if found. Or perhaps even delegate to it (there's underlying ValueInstantiator that should be usable).
Other similar check could be done for @JsonValue.

If there's a bug filed I could help in changing deserializer.

This does not remove the need for having a way to disable registration of modules; but I thought this could already be overridden?

-+ Tatu +-

For more options, visit https://groups.google.com/d/optout.

[Christer Sandberg]

That would be awesome!

I've created an issue here: https://github.com/dropwizard/dropwizard/issues/549

Thanks,

Christer

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-user/IG0cdKEzTVg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dropwizard-us...@googlegroups.com.

[David Eriksson]

Hi,

Would you mind sharing your reflection code? I have a similar issue for PermissiveEnumDeserializer in FuzzyEnumModule. (See https://github.com/dropwizard/dropwizard/issues/549)


Cheers,

David