Problem with @JsonIgnoreProperties on recursive property (regression in 2.8)

[anujkumar04]

I am getting an exception with jackson databind version 2.8.0 and later, everything works fine with any version below 2.8.0.
Issue is, if I have a property name with an underscore and the letter after it is NOT the same as the first letter, then things blow up.

For example I have a Person class which contains a Set which has the name as "person_z" which fails.
But if I rename it to "person_p" it works.

public class Person {
    @JsonProperty("name")
    private String name;
    @JsonProperty("person_z") // renaming this to person_p works
    @JsonIgnoreProperties(value = {"person_z"}) // renaming this to person_p works
    private Set<Person> personZ;
}

public class TestJackson {

    public static void main(String[] args) throws IOException {

        String st =" [ {\n"
                + "    \"name\": \"admin\",\n"
                + "    \"person_z\": [" // renaming this to person_p works
                + "      {"
                + "        \"name\": \"admin\""
                + "      }"
                + "    ]"
                + "  }]";

        ObjectMapper mapper = new ObjectMapper();
        mapper.readValue(st, mapper.getTypeFactory().constructCollectionType(List.class, Person.class));
    }

}

Exception in thread "main" com.fasterxml.jackson.databind.JsonMappingException: No _valueDeserializer assigned
at [Source: [ {
"name": "admin",
"person_z": [ { "name": "admin" } ] }]; line: 3, column: 41] (through reference chain: java.util.ArrayList[0]->com.example.Person["person_z"]->java.util.HashSet[0]->com.example.Person["name"])
at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:261)
at com.fasterxml.jackson.databind.DeserializationContext.reportMappingException(DeserializationContext.java:1233)
at com.fasterxml.jackson.databind.deser.impl.FailingDeserializer.deserialize(FailingDeserializer.java:27)
at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:490)
at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:101)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:276)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:140)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:277)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:249)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:26)
at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:490)
at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:101)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:276)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:140)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:277)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:249)
at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:26)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3789)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2871)
at com.example.TestJackson.main(TestJackson.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

[cowtowncoder]

Yes, I can reproduce the issue as reported (and even simplified form). For what it is worth, property need not be a Collection (and in fact if it is, it probably wouldn't behave as implied in test); straight POJO reference also has the issue.

[cowtowncoder]

Turned out to be rather complicated to fix, but managed to do it. Not sure what exactly broke it, either, may have been working "accidentally". Either way, fix will be in 2.8.8 and 2.9.0 (or .pr3 if we release such).