Excessive rigidity: Hardcoded class reference prevents flexible implementations of Object Id Resolvers in Json

[DavidIAm]

Search before asking

• [X] I searched in the issues and found nothing similar.

Describe the bug

I want to adapt an awkward, custom form of self-referencing structure into a (more?) standard one so that other elements of the system can use standard JSOG library to read it. I am unable to write a custom resolver that manages the pattern of using references for a model and pattern like this:

model:

JsonIdentityInfo(generator = JSOGGenerator.class, property = "arbitraryFieldName", resolver=HypotheticalPropertyIdResolver.class)
class Node {
  int arbitraryFieldName;
  Node child;
  Node parent;
}

deserializing structure that looks like

{ "arbitraryFieldName": 5,
  "child": {
    "arbitraryFieldName": 6,
   "parent": 5
  }
}

serialization should look like

{ "@id": 1,
   "arbitraryFieldName": 5,
  "child": {
    "arbitraryFieldName": 6,
   "parent": { "@ref": 1 }
  }
}

Version Information

2.16.1

Reproduction

So when you look at

https://github.com/FasterXML/jackson-databind/blob/08517c298c2ce91ce2a31fc22c14a415168c1e59/src/main/java/com/fasterxml/jackson/databind/deser/AbstractDeserializer.java#L142

You see that it checks to see what the generator is (specifically 'PropertyGenerator' here) to change its behavior.

I was unable to make a custom generator to have flexible reading capability (to read the property style reference) and write the JSOG style reference, because the only way to get the property style reference deserialization behavior is to use that specific class - not even a descendent/extension of that class - but THAT CLASS SPECIFICALLY. As a generator, not even resolver. You can imagine my irritation.

Delegating this logic to the implementation (doesn't this belong in the resolver?) so that the implementation chosen can decide what do here to rather than having the abstract Deserializer consider PropertyGenerator utilization a special case to check for when resolving ids is entirely appropriate.

Expected behavior

It seems logical to me that the implementation chosen for the resolver should have the chance to determine the logic by which to determine the id for a record, by calling into it and most of the time being delegated to a default implementation.

Additional context

No response