@JsonBackReference property is always ignored when deserializing since 2.9.0

[reda-alaoui]

We recently moved from Jackson 2.8.x to 2.9.0.
Since then we started to experiment a new problematic behaviour.

Now a property annotated with @JsonBackReference is NEVER deserialized, while before it was sometimes the case.

I think it is linked to e088920.

The property is removed in BeanDeserializerBuilder#addBackReferenceProperty():

/**
     * Method called to add a property that represents so-called back reference;
     * reference that "points back" to object that has forward reference to
     * currently built bean.
     */
    public void  addBackReferenceProperty(String referenceName, SettableBeanProperty prop)
    {
        if (_backRefProperties == null) {
            _backRefProperties = new HashMap<String, SettableBeanProperty>(4);
        }
        // 15-Sep-2016, tatu: For some reason fixing access at point of `build()` does
        //    NOT work (2 failing unit tests). Not 100% clear why, but for now force
        //    access set early; unfortunate, but since it works....
        prop.fixAccess(_config);
        _backRefProperties.put(referenceName, prop);
        // also: if we had property with same name, actually remove it
        if (_properties != null) {
            _properties.remove(prop.getName());
        }
        // ??? 23-Jul-2012, tatu: Should it be included in list of all properties?
        //   For now, won't add, since it is inferred, not explicit...
    }

Since 2.9.x (tested on 2.9.0 and 2.9.3), BeanDeserializerFactory.addBackReferenceProperties passes a SettableBeanProperty named as the annotated property.
In 2.8.x, the prop.getName() returns defaultReference.

Because of that, the property is always removed from the property map.

I am creating a PR with at least unit test to reproduce.

[reda-alaoui]

PR contains a unit test and a fix.

[cowtowncoder]

Hmmh. Perhaps there is some misunderstanding here, but property annotated with @JsonBackReference should never come from JSON: the whole idea is that it should be automatically created as counterpart to parent (managed) reference.

But I'll think about this a bit, and see what changed: code for removing property did not seem to change.

[cowtowncoder]

Ok. So 2.8 code was wrong, trying to use reference-name which is not what intent was. So removal was useless; it should never match, and if it ever did that'd be accidental.
2.9 does what code was meant to do, for better or worse.

Then again since there are no unit tests to verify behavior either way removal does not seem like something important for solving a problem or supporting a use case.

So... I am bit torn here. I think usage of explicitly setting back reference from JSON is bit wrong.
But maybe there is no harm in allowing that.

Let me think this over: I may accept the patch, but just comment out removal part (without changing name used for removal).

[cowtowncoder]

As per above thoughts, I conditionally include the change for 2.9.4. I am little bit concerned there might be cases for which original removal was intended, but let's hope my concerns are unfounded.