Deserialize time-only XMLGregorianCalendar

[rgoldberg]

If StdDeserializer#_parseDate(JsonParser DeserializationContext) throws InvalidFormatException when parsing an XMLGregorianCalendar using the Jackson date format, fallback to parsing using the XML Schema date / datetime / time / etc. lexical representation.

This adds support for time-only XMLGregorianCalendar.

This is an implementation for #1165.

Can this be backported to 2.7.4, and also included in 2.8.0?

[cowtowncoder]

Thank you for your help here.

I am not quite sure what the nested handling here is meant to achieve. From comments it would seem like it would be to support "accept single value as array" feature; but this is not responsibility of value deserializers; it is something array/Collection deserializers take care of. So I think that does not belong here.

Other than this code does a fallback, which probably makes sense.

[rgoldberg]

I would normally agree that "accept single value as array" shouldn't be implemented here.

But, the existing CoreXMLDeserializers.Std#deserialize(...) calls StdDeserializer#_parseDate(...).

_parseDate(...) handles "accept single value as array" in the recursive code after the comment // Issue#381 (which refers to issue #381 & PR #384).

Therefore, I thought that I might need to handle this same situation in my new code.

e.g., if _parseDate(...) throws an InvalidFormatException in the middle of the recursion after it has found the first non-array descendant, then the depth of the array nesting will be lost because the recursion will have terminated, but the JsonParser will already have been advanced to the first non-array descendant.

When I catch the exception in my new CoreXMLDeserializers.Std#parseXMLGregorianCalendarNotNested(...), and then try to fallback to calling _dataTypeFactory.newXMLGregorianCalendar(String), I won't know how deeply nested the value was, so I won't be able to unwind the JsonParser to the correct depth of nested arrays, nor verify that none of those nested arrays contain any other elements. If one of the nested arrays does contain another element, I should throw a JsonMappingException, just like _parseDate(...) does.

So, I need to get the depth before I call _parseDate(...), so that I have the depth as an int to use in the fallback catch block.

I should only remove the iterative nested array handling if one of the following is correct:

1. the recursive nested array handling should also be removed from _parseDate(...)
2. the recursive nested array handling should be left in _parseDate(...), but it turns out that whenever CoreXMLDeserializers.Std#deserialize(...) is called, the nested arrays have already been processed, and therefore _parseDate(...) will never recurse in this situation (it's just that _parseDate(...) might be called from other methods, so it needs the recursive handling for these other circumstances, but not for deserialize(...)).

Does what I'm saying make sense?

[cowtowncoder]

Oh. Yes you are absolutely right -- I had forgotten that there is such handling sprinkled around in a few places.
What threw me off was the handling of variable number of nested scopes; and even that does work. Note, however, that such nesting is not supported elsewhere, so it's probably not worth implementing here either (I understand that it's technically not that much more complicated to do... but still, single level is all that works elsewhere).

With that, it makes bit more sense. I'll try to go over code again tomorrow.

[rgoldberg]

I would imagine that the best way to universally handle nested single-element arrays would be to refactor the Jackson code to use my iterative nesting handling before deserialize(...) is called, and my iterative un-nesting after deserialize(...) is called. I wanted to limit the scope of my changes, however, so I just embedded it in the XMLGregorianCalendar deserialization code to support everything that the old version did.

Thanks for looking over this.

[cowtowncoder]

@rgoldberg Yeah the whole nesting/unnesting is an unfortunate detour.

[rgoldberg]

Do I need to change anything?

[cowtowncoder]

@rgoldberg no I think you are good. Next (and last I hope) question: have I asked for a CLA yet?

It's found from https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf and typically you print, fill & sign, scan and email to info at fasterxml dot com. We need this from all contributors, but just once before first commit. If you could do this, I can merge the patch and make any minor tweaks I'd like.

[rgoldberg]

Just emailed the signed CLA.

[cowtowncoder]

Hmmh. I wish there was a unit test here... I will rewrite this patch slightly, but would prefer not breaking additional processing. I just realized that the base class already takes care of unwrapping, so there should not be need to handle it here.