Exception when parsing `List`s of mixed content (since 2.13.0)

[cornwe19]

In Jackson 2.12 the following junit example test (written in Kotlin) works as I'd expect it to

@JsonIgnoreProperties(ignoreUnknown = true)
data class Tspan(
    @field:JacksonXmlText
    var content: String? = null
)

@JsonIgnoreProperties(ignoreUnknown = true)
class Text(
    @field:JacksonXmlElementWrapper(useWrapping = false)
    @field:JacksonXmlProperty(localName = "tspan")
    var spans: List<Tspan>? = null
)

class ExampleTest {
    @Test
    fun svgExample() {
        val text = XmlMapper().readValue("<text>Mixed <tspan>content</tspan> should<tspan> work</tspan></text>", Text::class.java)

        assertThat(text.spans, hasSize(2))
    }
}

But when I upgrade to 2.13, I get the following error

Unexpected non-whitespace text (' should' in Array context: should not occur (or should be handled)
 at [Source: (StringReader); line: 1, column: 49] (through reference chain: com.visualdx.api.kmax.graphql.Text["tspan"])
com.fasterxml.jackson.databind.JsonMappingException: Unexpected non-whitespace text (' should' in Array context: should not occur (or should be handled)
 at [Source: (StringReader); line: 1, column: 49] (through reference chain: com.visualdx.api.kmax.graphql.Text["tspan"])

This feels like a bug, but I'm not sure if there's some workaround or setting I'm missing somewhere.

[ptziegler]

I ran into the same issue earlier today. This problem seems to have been introduced with 6c37f48

// 29-Mar-2021, tatu: This seems like an error condition...
// How should we indicate it? As of 2.13, report as unexpected state
 throw _constructError("Unexpected non-whitespace text ('"+_currText+"' in Array context: should not occur (or should be handled)"

For example, following entry is triggering this "error state". I think throwing an error is the wrong course of action here, so I suggest removing this error check again.

<metaData>
	<data key="MadeWith">Created with XXX</data>
	<data key="Version">12345</data>
</metaData>

Is there a chance this can be fixed? Because right now, it's blocking us from updating to a newer version.

[cowtowncoder]

Sounds like something to address, yes.

I know there is a test but it'd be great to get a simpler one if possible: also, plan Java as I assume this is not Kotlin-specific.
Put another way: a unit test reproduction would make it easier for me to see what exactly is going on. Use of @JsonIgnoreProperties(ignoreUnknown = true), for example, tends to hide all kinds of real issues.

[cowtowncoder]

@ptziegler Any chance you could provide full reproduction; or at least POJOs being used? Your case is somewhat different as it only contains (ignorable) white-space, not non-empty content, so it might be supportable.

The original case isn't possible to map to POJOs (can be mapped to JsonNode, however, or as java.lang.Object).

[ptziegler]

Any chance you could provide full reproduction; or at least POJOs being used?

@cowtowncoder I've created #604

[cowtowncoder]

Thank you @ptziegler !

[wickstopher]

Hello! I'm wondering if there is any recent movement on this issue? Spring Framework 6.1 was released last November, raising the minimum requirement for Jackson to 2.14 (https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x#upgrading-to-version-61).

Our project relies on being able to parse mixed content, and this issue is blocking us from upgrading to the latest version of Spring, as we need to pin 2.12 to avoid this bug. I'd be happy to look into contributing back to the project in order to expedite this fix if possible.

[cowtowncoder]

Unfortunately I haven't had time to look into this @wickstopher. There is a failing test under src/test/java/com/fasterxml/jackson/dataformat/xml/failing/UnexpectedNonWhitespaceText509Test.java for reproduction; all help would be appreciated.

Fix would need to go in 2.16 branch or later (2.18 is the next minor version to add but unless fix requires API change, can be merged to latest open branch which I think is 2.16).

[cowtowncoder]

Also verified that the problem exists in 2.18 branch and not been fixed by some other changes.