Deserialization issue with @JsonIgnore and @JsonCreator + @JsonProperty for same property name

[jskierbi]

Issue originally found on jackson-module-kotlin: FasterXML/jackson-module-kotlin#124. Issue reproducible with Java code.

Entity class:

static public class Foo {
  @JsonIgnore 
  public String query;

  @JsonCreator
  @ConstructorProperties("rawQuery")
  public Foo(@JsonProperty("query") String rawQuery) {
    query = rawQuery;
  }
}

Fails this test:

Foo deserialized = new ObjectMapper().readValue("{\"query\": \"bar\"}", Foo.class);
assertEquals("bar", deserialized.query);

[cowtowncoder]

One quick note: example is ambiguous, and I wonder if it should fail -- first constructor is given two different names ("rawQuery", "query"), and it is not clear as to which one should be used.
It would be possible to think of "query" as being more specific, being on parameter, whereas "rawQuery" is associated with constructor itself.

So maybe it's just matter of clarifying that this is indeed the proper annotation precedence...

[jskierbi]

That is my thinking. Exact same behaviour without additional ctor props annotation is triggered in Kotlin: data class Foo(@JsonProperty("query") rawQuery: String) (with jackson-module-kotlin) - I would expect "query" to have precedence over ctor parameter name

Actual behaviour is here:

jackson-databind/src/main/java/com/fasterxml/jackson/databind/introspect/POJOPropertiesCollector.java

Lines 481 to 482 in f350b20

	POJOPropertyBuilder prop = (expl && impl.isEmpty())
	? _property(props, pn) : _property(props, impl);

Named ctor param name is reported as implicit property name, thus property initially gets "rawQuery" name upon discovery, then is renamed to "query" in rename phase. When same property exists in the class with @JsonIgnore annotation, "query" property gets into ignored, then rename phase changes "rawQuery" property into "query", but originally ignored "query" stays in the ignored. My idea is to unignore new name of the property during rename phase - this, in my opinion, should introduce least possible behavioural changes.

What do you think?

[cowtowncoder]

@jskierbi In case of constructor parameter/argument this is fully defined since that is consider "implicit" name, similar to name detected from "getX()": explicit annotation does have precedence.
Same is not as clear between annotations (for example, if same accessor has both @JsonIgnore and @JsonProperty, which one wins? Ignoral, I think, but that's judgment call).
However, coupled with "closer" scope I could see how it can be resolved.