JsonWriteContext could hold current value.

[Antibrumm]

It would be great if we could access the currentValue from the JsonWriteContext. It would give us more flexibility during filtering.

In my particular case I have implemented a BackReferenceAwareBeanSerializer to be able to break bi-directional relationships. As a side effect I'm also able to break circular references within the path.

For this to work the JsonWriteContext needs to know the currentValue.
Unfortunately the JsonWriteContext.writeValue method is final, as well as the UTF8JsonGenerators.writeStartObject/writeStartArray methods, so I was not able to simply call setCurrentValue directly from within these classes. I had to abuse a TypeSerializer as this one can act as a callback on any write operation.

Currently I had to override these classes and it would be great if that could be simplified:

• JsonWriteContext (add currentValue attribute)
• UTF8JsonGenerator (set _writeContext to new context)
• MappingJsonFactory (override _createUTF8Generator and copy to use new generator)
• AsPropertyTypeSerializer (override all writePrefix methods to set currentValue on context)
• BeanSerializerBase (that my actual use-case)
• ObjectMapper (call setDefaultTyping and setSerializerFactory)

During serialization the BackReferenceAwareBeanSerializer walks back up the context hierarchy and compares the pojo with the currentValues and writes the "level" of that as @backReference.

The ObjectIdGenerator feature would not be sufficient here as generated ids are "global". This implementation simply breaks references but continues serializing each path indepentantly.

[cowtowncoder]

Interesting thought. I'll have to think about this for a bit, but this might work; I assume it would matter with structured types (i.e. things that come from JSON Object, Array).

One practical challenge may be that some datatypes use an alternative JsonStreamContext sub-classes; however, this would just mean that methods should be added there, to be overridden by sub-classes.

Another, possibly bigger challenge is that in some cases current value is known quite late: specifically, when using Creator methods, instance can only be created once all parameters for that are read.
However that is just a limitation.

Maybe I can play with this and verify there is no measurable performance penalty for added state, update calls.

[cowtowncoder]

One additional comment: earlier I was thinking of storing the current POJO (and perhaps Collection/Map) being handled in DeserializationContext (or, more generally, DatabindContext).
But while that would work, doing this via JsonParser/JsonGenerator has two specific benefits:

1. It handles nesting (i.e. allows access to full parent stack, not just latest one)
2. It is available from streaming level

There is also one potential downside -- when constructing temporary readers (from buffered content), access may be compromise -- but that is probably something that can be solved relatively easily.

[cowtowncoder]

Implemented streaming API support as per:

FasterXML/jackson-core#168

and so far no measurable negative performance impact found; so I think this can be added as suggested. I'll add it for both reading and writing, as it is likely to be of some use for both.

[Antibrumm]

Nice work. Thanks.

I don't think i will have time this week to play with the snapshot and give you some feedback already, but i hope next week will be fine. (I'm just using the serializer part for now.)

[cowtowncoder]

No prob: I need to add actual tests myself, to verify handling.

I think this is a great addition, thanks once again for suggesting it. I can now also mark another RFE obsolete for databind, since this should cover the intended use case.

[cowtowncoder]

Ok, as per earlier notes, implemented both for JsonGenerator and JsonParser. Probably more useful for generator, but seemed logical to support for both. Information stored in parsing/output context, accessed via parser/generator for convenience.
And I tried to add proper set methods in standard serializers/deserializers; however, it is quite possible I missed some cases. If so, just let me know and I'll add calls (or merge Pull Request for the same).