StackOverflowError with contentConverter that returns array type

[fschopp]

Jackson version: 2.3.0

The following code snippet

static class A { }

static class B {
    @JsonSerialize(contentConverter = AToStringConverter.class)
    public List<A> list = Arrays.asList(new A());
}

static class AToStringConverter extends StdConverter<A, List<String>> {
    @Override
    public List<String> convert(A value) {
        return Arrays.asList("Hello world.");
    }
}

@Test
void testBSerialization() throws Exception {
    new ObjectMapper().writeValueAsString(new B());
}

produces the following endless recursion:

[...]
at com.fasterxml.jackson.databind.ser.std.StdSerializer.findConvertingContentSerializer(StdSerializer.java:252)
at com.fasterxml.jackson.databind.ser.impl.StringCollectionSerializer.createContextual(StringCollectionSerializer.java:91)
at com.fasterxml.jackson.databind.SerializerProvider.handleSecondaryContextualization(SerializerProvider.java:835)
at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:503)
at com.fasterxml.jackson.databind.ser.std.StdSerializer.findConvertingContentSerializer(StdSerializer.java:252)
at com.fasterxml.jackson.databind.ser.impl.StringCollectionSerializer.createContextual(StringCollectionSerializer.java:91)
at com.fasterxml.jackson.databind.SerializerProvider.handleSecondaryContextualization(SerializerProvider.java:835)
at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:503)
[...]

It seems that the @JsonSerialize annotation is applied both before and after the conversion.

[fschopp]

Found two issues that are related in the sense that they also pertain to serializing statically typed arrays: #358 and #359. Looks like a minefield to me... :)

[cowtowncoder]

Your guess on cause is probably correct: annotation handling is difficult because it is difficult to figure out exact applicability when a chain of conversions (of handlers) is executed.
I hope to find out how this can be resolved.

In the meantime I think the safest work-around actually involves use of JsonNode (or specifically ArrayNode) since those are not generic types, nor use contextual variations.

[cowtowncoder]

I can reproduce this successfully with sample code.

[fschopp]

As part of the fix, I suggest to add a comment to the JavaDoc about the precedence of the various @JsonSerialize properties. For instance, if both a serializer and a converter are given, what is the specified behavior? Possible options include:

• first the converter is applied, and then the using property overrides the serializer of the conversion result type
• converter is used, and as is ignored
• as is used, and converter is ignored

The JavaDoc already has some comments in that direction (e.g., it mentions that "some properties block others"), but it would be great to be more specific.

[cowtowncoder]

Right, this is a case where options overlap. My thinking is that if en explicit serializer (using etc) is specified, that is to be used as-is, and converter to be ignored. Type override is still used, although it does not necessarily matter.
Only if no explicit serializer is specific is converter considered.

Question of as is interesting one; my gut feeling is that since it specifies input type (for converter), it should not have much if any effect -- converter's output type is what should be used for locating serializer to use.
But things get even more complicated with structured types; so perhaps it would be best to state that none of type modifiers are to be used with converters.

[cowtowncoder]

Alas: it looks like my fix did not fully work; it just happened to add a different flaw that did fix converter problem, but caused other issues. Essentially removal of lock failed, and so lock lasted until end of current processing (writeValue()). I am not fixing the problem with mechanism locking uses, and once lock lifecycle works as intended, the original problem reappears.

So it's back to square one, with 2.7.4. :-(