You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Turning on the SerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED and DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY of ObjectMapper breaks LngLatAlt deserialization
#68
Open
Strongbeard opened this issue
Jun 18, 2024
· 1 comment
· May be fixed by #69
The LngLatAltSerializer and LngLatAltDeserializer cannot properly handle the SerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED and DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY features being turned on in an ObjectMapper.
Details
Running the following code throws the below redacted exception. Substituting the Polygon with a similar MultiPolygon or MultiLineString should produce a similar exception.
I believe the issue stems from the following two json Strings that are produced and then interpreted by mapper.readValue(str, Polygon.class) when SerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED is turned on or off, respectively. The former throws the exception while the latter does not, due to expecting the 3rd set of array brackets. When the feature is turned on, the outermost brackets are not written since they are "unwrapped" by the feature. Thus, in the former scenario, jackson "opens" both arrays since it knows from the type that there are 2 outer list/array types and tries to pass the 1st DoubleNode to the LngLatAltDeserializer, which expects the [ token instead.
Use annotations to turn off the SerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED and DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY features for only the geojson classes so that said features can still be turned on for the surrounding json document without breaking serialization/deserialization of the geojson. This might be the prefered solution since RFC7946 does not yet appear to have any examples of "unwrapped single element arrays".
Perhaps there is a way to indicate to the jackson library that LngLatAlt objects should be treated like an array when serializing/deserializing them so it properly generates the 3rd wrapping ArrayNode even when the above features are turned on? Maybe either making LngLatAlt extend List or having the LngLatAltDeserializer advertise that it produces an array by overriding the hangleType() function to return List.class or logicalType() to return LogicalType.Array?
The text was updated successfully, but these errors were encountered:
Software Versions:
17.0.11-amzn
managed by sdkman2.15.4
1.14
Executive Summary
The
LngLatAltSerializer
andLngLatAltDeserializer
cannot properly handle theSerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED
andDeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY
features being turned on in anObjectMapper
.Details
Running the following code throws the below redacted exception. Substituting the
Polygon
with a similarMultiPolygon
orMultiLineString
should produce a similar exception.I believe the issue stems from the following two json
Strings
that are produced and then interpreted bymapper.readValue(str, Polygon.class)
whenSerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED
is turned on or off, respectively. The former throws the exception while the latter does not, due to expecting the 3rd set of array brackets. When the feature is turned on, the outermost brackets are not written since they are "unwrapped" by the feature. Thus, in the former scenario, jackson "opens" both arrays since it knows from the type that there are 2 outer list/array types and tries to pass the 1stDoubleNode
to theLngLatAltDeserializer
, which expects the[
token instead.Potential Solutions
SerializationFeature.WRITE_SINGLE_ELEM_ARRAYS_UNWRAPPED
andDeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY
features for only the geojson classes so that said features can still be turned on for the surrounding json document without breaking serialization/deserialization of the geojson. This might be the prefered solution since RFC7946 does not yet appear to have any examples of "unwrapped single element arrays".LngLatAlt
objects should be treated like an array when serializing/deserializing them so it properly generates the 3rd wrappingArrayNode
even when the above features are turned on? Maybe either makingLngLatAlt
extendList
or having theLngLatAltDeserializer
advertise that it produces an array by overriding thehangleType()
function to returnList.class
orlogicalType()
to returnLogicalType.Array
?The text was updated successfully, but these errors were encountered: