Knowing the current full path when deserializing an object

[indyteo]

Hi,

I wonder if there's a way to know the current full path of the object being deserialized.

My usecase is to keep a reference to that path in the created object, just as a kind of technical/debugging information (because it can be tricky otherwise, if an issue occurs later with that created object, to trace back to where in the params it was created from).

I know how to get that path when a JacksonException occurs (using JacksonException#getPath()), but how could I achieve the same in a normal scenario (without exception)? Or, alternatively, would there be a way to trigger a fake exception to get that path (I know creating an exception as an impact on performance, but it isn't really an issue, since parameters parsing is just an initialization step never repeated later)?

To be clear, my issue isn't to hook into the object creation process using a custom delegating deserializer to add an automatically computed value to a transient field of the object; it is to compute the actual value to add, which is the full path currently parsed.

And also note that I'm aware of parser.streamReadContext().pathAsPointer() (to get the relative path from the current parser) & context.getParser() (to get the root parser). None of those actually work for me, because I am creating intermediate parsers elsewhere in my deserialization process*, thus I only have relative paths, or incomplete path (from root until that root parser 1st delegated to another one). If I could track the hierarchy of sub-parsers being in use, I could reconstruct the full path. But parsers does not have a reference to a possible parent. If no other alternative available, would that be a possible contribution I could do (to make to possible to reference a parent parser when creating one, so we can traverse the parser chain to get the full path)?

Thanks

*Such intermediate parsers are needed because I need to buffer the whole tree being parsed (JsonNode node = parser.readValueAsTree();) in some custom deserializers, that'll later "resume" parsing of (parts of) that tree using return context.readTreeAsValue(node, AnotherParams.class);

[cowtowncoder]

This is a hard problem. For performance reasons we do not construct Location or Path information for all tokens, and that is unlikely to change. But linking of StreamReadContext could be considered, for example.

[indyteo]

I understand, and it was what I expected. I'll have a look at linking StreamReadContexts when creating a new parser, to see if it requires a lot of changes or not.