In a @JsonPath projection a List<interface> property always returns a list with only one element

[jekutzsche]

The @JsonPath projection of a List of an interface type returns only the first element even if the list should contain more elements.

The following code hopefully makes the circumstances clear.

var payload = template.exchange("https://…", HttpMethod.GET, new HttpEntity<Void>(headers), UserPayload.class).getBody();

var users = payload.users();
users.size() == 1 is also true if the list had to contain more elements


@ProjectedPayload
interface UserPayload {

	@JsonPath("$..person")
	List<Users> users();

	interface Users {

		public String getFirstName();
		public String getLastName();
	}
}

Responsible for the error is the following code in InputMessageProjecting.invoke:

if (returnType.getRequiredActualType().getType().isInterface()) {

    List<?> result = context.read(jsonPath);
    return result.isEmpty() ? null : result.get(0);
}

[mp911de]

I was able to reproduce the issue by using ProjectingJackson2HttpMessageConverter directly. Our unit tests don't reproduce the issue as the JSON path result is wrapped in another list which renders the correct result. Need to investigate further why using ProjectingJackson2HttpMessageConverter doesn't show this behavior.

[mp911de]

Okay, so the actual path definition makes the difference, whether the path is definite or not. Only definite paths lead to additional list wrapping. Can you provide a sample for your input JSON?

[jekutzsche]

Yes of course, here is a sample:

[
    {
        "creationDate": 1610111331413,
        "changeDate": 1610111332160,
        "person": {
            "caption": "Test2 TEST2",
            "firstName": "Test2",
            "lastName": "Test2"
        }
    },
    {
        "creationDate": 1609775450502,
        "changeDate": 1609775451333,
        "person": {
            "caption": "Test TEST",
            "firstName": "Test",
            "lastName": "Test"
        }
    }
]

[mp911de]

Okay, thanks. The combination of a scan token with an array response leads to a non-definite path and therefore the JSON path library doesn't wrap the response in a nested list. Checking for a non-definite path and then applying the proper collection handling in combination with checking the return type does the trick.