Allow setting of default attributes on the SerializerProvider

[nsoft]

I recently found myself trying to communicate what amounts to a feature flag into a custom serializer meant to be used by an ObjectIdGenerator via @JsonIdentityInfo(generator=), and setting an attribute on the SerializizerProvider seems to be a way to do that. Initially, I was quite pleased to find that mapper.getSerializerProvider().setAttribute() existed and at first blush it seemed perfect, but shockingly that produces a null pointer exception. This can be seen in both 2.10.2 and in 2.19.0 with this trivial example:

import com.fasterxml.jackson.databind.ObjectMapper;

public class JacksonNPEExample {
  public static void main(String[] args) {
    ObjectMapper mapper = new ObjectMapper();
    mapper.getSerializerProvider().setAttribute("foo", "bar");
  }
}

I am aware that one can set the attribute via mapper.writer().withAttribute() but that's inconvenient in systems where an ObjectMapper is injected, because then EVERY place that mapper is used, the attribute must be set independently.

I notice that the javadoc on setAttribute is focused on overriding defaults, but it seems like this method should throw a better exception suggesting the correct method, and there should be a setDefaultAttribute() or some other mechanism to allow intialization of a mapper with default attributes (or if it exists it should be mentioned in this javadoc because I couldn't find it ;) ).

Of course I could use a system property, but that's an ugly, needlessly global solution that will cross talk across all instantiated mappers in the JVM.

[cowtowncoder]

Quick note: this

mapper.getSerializerProvider().setAttribute("foo", "bar");

is not supported usage: serialization context (SerializerProvider) should not be accessed via ObjectMapper by application code. Only databind package itself should do that. Only instances provided on callbacks should be used.
Javadocs say:

     * Note that returned instance cannot be directly used as it is not properly
     * configured: to get a properly configured instance to call, use
     * {@link #getSerializerProviderInstance()} instead.

(although it should warn application code against using the other method either)

so basically instance is not valid for usage.

But there is a way to set default attributes:

    public ObjectMapper setDefaultAttributes(ContextAttributes attrs) {

and I am bit surprised that you did not notice that...

[nsoft]

I did notice setDefaultAttributes(ContextAttributes attrs) but ContextAttributes.Impl has protected constructors, instances are only available via writers and readers (AFAICT, apologies if I missed something), which leaves me back at my prior comment about inconvenience for systems injecting ObjectMapper.

[cowtowncoder]

Ok. Usage is not super intuitive, but from unit test (ContextAttributeWithSerTest):

        ContextAttributes attrs = ContextAttributes.getEmpty()
                .withSharedAttribute(KEY, Integer.valueOf(72));
        ObjectMapper mapper = JsonMapper.builder()
                .defaultAttributes(attrs)
                .build();
        // or `ObjectMapper.setDefaultAttributes()` for Old Style

is the way to go. Note fluent style for construction, instead of constructor usage.

No configuration should require modifying SerializerProvider directly.

[nsoft]

Also

  public SerializerProvider getSerializerProviderInstance() {
        return _serializerProvider(_serializationConfig);
    }

calls

    /**
     * Overridable helper method used for constructing
     * {@link SerializerProvider} to use for serialization.
     */
    protected DefaultSerializerProvider _serializerProvider(SerializationConfig config) {
        return _serializerProvider.createInstance(config, _serializerFactory);
    }

which leaves us with the same problem as

  public SerializerProvider getSerializerProvider() {
        return _serializerProvider;
    }

[cowtowncoder]

Correct: you should not attempt to globally configure SerializerProvider directly, either blueprint instance or per-call instance. That's not meant as public extension point for application code.

[nsoft]

    protected final static Impl EMPTY = new Impl(Collections.emptyMap());

        public static ContextAttributes getEmpty() {
            return EMPTY;
        }

Your suggestion seems to modify a global context, and it seems to be backed by

    /**
     * The empty map (immutable).  This map is serializable.
     *
     * @see #emptyMap()
     * @since 1.3
     */
    @SuppressWarnings("rawtypes")
    public static final Map EMPTY_MAP = new EmptyMap<>();

[cowtowncoder]

Your suggestion seems to modify a global context,

No. :)

Yes, "empty" instance is a global, immutable instance. But call

.withSharedAttribute(key, value)

creates a new instance with different attribute value. It does not modify instance it is called on (because instances are immutable).

So this is the way to construct instances to use for default attribute values.

[nsoft]

OH here's what I didn't see.. a very unexpected side effect in withSharedAttribute()

    public ContextAttributes withSharedAttribute(Object key, Object value)
        {
            Map<Object,Object> m;
            // need to cover one special case, since EMPTY uses Immutable map:
            if (this == EMPTY) {
                m = new HashMap<Object,Object>(8);
            } else {
                m = _copy(_shared);
            }
            m.put(key, value);
            return new Impl(m);
        }

[cowtowncoder]

a very unexpected side effect in withSharedAttribute()

It is a commonly (consistently, even) used pattern in Jackson: methods named "withXxx()" create new copies, do not modify instances themselves.

(in some places full Builders are used instead, and Jackson 3.x more so)

[nsoft]

I think that's a stretch for folks to discover. One normally stops at any sort of .emptyFoo() method is used because normally those are immutable and unusable. Also, fluent interfaces normally return the same instance, so that's unexpected too.

[cowtowncoder]

Regardless, this is they way to do it.

I am open to Javadoc improvements (those would be great), but functionality-wise it's all that is needed and has been available for years.

[nsoft]

Anway, thanks for the help.