Closed ghost closed 7 years ago
Thank you for reporting this. I suspect problem comes from Guava module declaring content model that differs from actual serialization: that is, it claims to serialize as simple string
, but that can not be: it produces something like Map<String,String[]>
.
If so it'd be Guava problem -- but I'll first look into this to see if that is true.
Doh! At this thought serializer implemented discovery properly, but just realized that code SHOULD differ from standard MapSerializer
to account for that intermediate Array node...
Reproducing the issue can be done easily enough (although due to deps, need to stash in jackson-compat-minor
or such). But fixing gets bit involved because there's no good way to indicate wrapping as is: rather, and intermediate JsonSerializer
(or its equivalent) is needed.
Done -- this will be fixed via
https://github.com/FasterXML/jackson-datatypes-collections/issues/19
which will be included in 2.8.10
and 2.9.1
once those are released.
In the meantime may want to use snapshot builds or local builds.
Using jackson version
2.9.0
One of our classes utilizes Guava's Multimap. It is a
Multimap<String, String>
. When attempting to write our object in Avro, the following exception is thrown:This is how we are are setting up the writer:
And the generated Avro schema looks something like:
And the class would look something like:
It would appear that these two libraries (jackson-dataformat-avro & jackson-datatype-guava), or more specifically,
AvroSchemaGenerator
&GuavaModule
, don't play nice together. Unless, I'm totally messing things up.