Serializing `BigDecimal` values inside containers ignores shape override

[Woodz]

Using the config overrides described in #1911

Reproduction pseudocode:

class Foo {
  public BigDecimal value;
  public List<Object> values:
}

Foo foo = new Foo();
foo.value = new BigDecimal("1.23");
foo.values = ImmutableList.of(new BigDecimal("2.34"));

ObjectMapper mapper = new ObjectMapper();
mapper.configOverrides(BigDecimal.class). .setFormat(JsonFormat.Value.forShape(JsonFormat.Shape.STRING));
mapper.writeValueAsString(foo);

Expected:
Both BigDecimals to be JSON Strings

Actual:
Only value is JSON String

Version: 2.9.6

[cowtowncoder]

Interesting. Hmmh. Thank you for reporting the problem. This may be tricky to handle due to lack of typing.
One quick question: do you think this still occurs with 2.9.10?

[cowtowncoder]

Verified, does occur with 2.10 too.
Unfortunately things go pretty deep: contextualization is called appropriately, but unfortunately bean property settings are lazily evaluated and in this case info is for container (List) and not elements -- so resolve information is actually wrong.

Will add a failing test first but then need to think careful of how this could be untangled...

[cowtowncoder]

I think I have an idea of how this problem could be resolved (by not passing property when locating secondary serializers (and maybe deserializers?)), but... it seems like possibly moderate risk of regressions. Chances are fix will need to go in 2.11, not 2.10 patch.

Trying out minimal change only introduces 1 actual regression failure for existing test suite, which is a good sign. But still.

Minimal fix itself is within PropertySerializerMap, findAndAddSecondarySerializer() methods: passing null instead of property, to prevent main property information from being propagated.
This might not be the right place (possibly it should be in method being called), but first need to figure out what is with the new test failure (related to Object Id).

[cowtowncoder]

Looking deeper, passing null for content serializers will not work as some information is actually used for content elements (like @JsonIgnoreProperties, content-converting serializer and something about Object Ids).

A much simpler short-term fix seems to be to remove lazy-caching of calculated JsonFormat.Value in ConcreteBeanPropertyBase -- it is speculative optimization, too, and although could guard it to verify given baseType matches that seems like a complication to preserve iffy optimization.

But I will probably also want to change how "secondary" serializers are fetched via SerializerProvider, for 2.11, to prepare for likely future work where we may need to start cleansing annotation information passed to secondary value serializers (compared to primary ones).