Changing JsonPathProvider to Jackson breaks the JsonPathLinkDiscoverer

[BeniaminK]

Changing JsonPath provider to JacksonProvider breaks the createLinksFrom in JsonPathLinkDiscoverer

By setting the Configuration of the JsonPath to JacksonJsonProvider - the createLinksFrom breaks it's usage (as it relies only on JsonSmartJsonPRovider)

Configuration.setDefaults(new Configuration.Defaults() {

    private final JsonProvider jsonProvider = new JacksonJsonProvider();
    private final MappingProvider mappingProvider = new JacksonMappingProvider();
      
    @Override
    public JsonProvider jsonProvider() {
        return jsonProvider;
    }

    @Override
    public MappingProvider mappingProvider() {
        return mappingProvider;
    }
    
    @Override
    public Set<Option> options() {
        return EnumSet.noneOf(Option.class);
    }
});

breaks almost all tests in the HalLinkDiscovererUnitTest.

However adding:

if (List.class.isInstance(parseResult)) {

	List<?> list = (List<?>) parseResult;

	return list.stream()
			.flatMap(it -> List.class.isInstance(it) ? ((List<?>) it).stream() : Stream.of(it))
			.map(it -> extractLink(it, rel))
			.collect(Links.collector());
}

in the JsonPathLinkDiscoverer file fixes those Tests (however still few other tests are broken).

I think the implementation in Spring shouldn't so closely rely on using net.minidev.json packages

[odrotbohm]

Would you mind stepping back and elaborate what you're trying to achieve, exactly? Ideally, in the form of a test case?

If customizing the configuration changes the way JsonPath works so fundamentally, is that maybe something worth bringing up with the JsonPath team? Just asking because we're not actively relying on JsonSmartJsonProvider but consistency in what's returned from JsonPath.read(…). If that significantly changes depending on the JsonProvider implementation, this is definitely something to discuss over there, as one cannot reliably write code against JsonPath then. How would we know, which cases we have to cover?

[odrotbohm]

I've investigated a little more, and it looks like we can indeed simply switch to List over JSONArray. It seems like the latter has always implemented List, so I don't remember exactly why we coded against the concrete class in the first place. Good catch, though!

[odrotbohm]

That's fixed and back-ported as far as 1.5.x.