BeanDeserializerModifier.modifyDeserializer() not applied to custom bean deserializers

[andreasbaus]

When trying to modify the default deserializer for java.time.Instant using a BeanDeserializerModifier, I noticed that the modifier is not actually applied. On the other hand, a BeanSerializerModifier works just fine.

The issue seems to be the following: in com.fasterxml.jackson.databind.ser.BeanSerializerFactory, method _createSerializer2 first looks for a custom serializer, stores it in a local variable ser:

                // Modules may provide serializers of POJO types:
                for (Serializers serializers : customSerializers()) {
                    ser = serializers.findSerializer(config, type, beanDesc);
                    if (ser != null) {
                        break;
                    }
                }

and at the end tries looking for matching modifiers and applies them if available, before returning ser:

        if (ser != null) {
            // [databind#120]: Allow post-processing
            if (_factoryConfig.hasSerializerModifiers()) {
                for (BeanSerializerModifier mod : _factoryConfig.serializerModifiers()) {
                    ser = mod.modifySerializer(config, beanDesc, ser);
                }
            }
        }
        return ser;

The BeanDeserializerFactory on the other hand just looks for a custom deserializer, and if found, returns it immediately:

        JsonDeserializer<Object> custom = _findCustomBeanDeserializer(type, config, beanDesc);
        if (custom != null) {
            return custom;
        }

without passing throug the logic handling deserializer modifiers - this only happens in the method findStdDeserializer, which would be called further down but only if none of the early returns before its invocation happen.

Shouldn't a deserializer modifier have a chance to be applied to a custom deserializer as well, just like a serializer modifier already is to a custom serializer? The way it currently is handled is kind of inconsistent.

Affected version: 2.9.9.1

(The reason that there is a custom serializer and deserializer registered for java.time.Instant by the way is that it comes from com.fasterxml.jackson.datatype.jsr310.JavaTimeModule.)

[cowtowncoder]

Hmmh. Good question... I would think that, yes, custom deserializers should also go through same process.

Timing for fixing this (assuming I can reproduce it) is good as it could go in 2.10: I'd be bit hesitant to do this in a patch.

[cowtowncoder]

Actually, looks like every other kind of custom deserializer has already been subject to modification and literally the only case this was missing is the custom "bean" deserializer.
So adding makes sense.