Tatu,
Thank you for quick response. I will dig into this a bit. I think 
ultimately, a custom deserializer/converter is going to be the cleanest 
approach.

Regards,

Eric.

On Friday, September 5, 2025 at 4:09:41 PM UTC-6 Tatu Saloranta wrote:

> On Fri, Sep 5, 2025 at 2:40 PM 'eric liprandi' via jackson-user
> <[email protected]> wrote:
> >
> > Hi,
> > StackOverflow question posted here
> > Cleaning up some code that is currently manually parsing various JSON 
> objects. It's all been pretty straightforward with one exception. I have 1 
> object left that has a property that is a string containing JSON. I need to 
> parse that string. I think the correct solution is to create a custom 
> deserializer for that. My refactoring has already caused much more changes 
> than what the team is comfortable with, so I am trying to skip the custom 
> deserializer.
> > My alternative is to try and use `@JacksonInject` and to have 
> `ObjectMapper` injected. Assuming that my Spring Boot application is 
> properly auto-configured with no customization to the `ObjectMapper`, it 
> should work out-of--the-box, correct?
> > I am getting errors both at runtime and in my tests (using `@JsonTest` 
> and `JacksonTester`). In both cases, it appears that the system is trying 
> to deserialize the `ObjectMapper` from the JSON string and is complaining 
> about Conflicting setters like:
> > "Conflicting setter definitions for property "defaultPropertyInclusion": 
> com.fasterxml.jackson.databind.ObjectMapper#setDefaultPropertyInclusion(com.fasterxml.jackson.annotation.JsonInclude$Value)
>  
> vs 
> com.fasterxml.jackson.databind.ObjectMapper#setDefaultPropertyInclusion(com.fasterxml.jackson.annotation.JsonInclude$Include)
> > "
> > Thanks in advance for any help.
>
> Injecting `ObjectMapper` should be possible, yes, but not for property
> that comes from JSON.
> (since otherwise Jackson will indeed try to deserialize JSON into
> `ObjectMapper` and that's not what you want).
> But even if you inject a mapper, something would need to use it. So it
> is probably not a working solution for your problem.
> This is based on some guessing based on description (since there's no 
> code).
>
> On custom deserializer: you probably know it but just in case: there
> are multiple ways to register custom deserializers: so instead of
> global registration you can use:
>
> @JsonDeserialize(using = MyJsonInJsonDeserializer)
> private CustomType values;
>
> But thinking out loud, I wonder if you could instead define a
> `Converter` that takes in, say `JsonNode` (or `String`) and then
> handles secondary conversion.
>
> @JsonDeserialize(convert = FromJsonConverter.class)
> private CustomType values;
>
> where FromJsonConverter would implement `Converter<String, CustomType>`.
> ... but it still does need `ObjectMapper`, which won't be available
> via `DeserializationContext`.
> ... unless you pass one as Contextual Attribute (see
> `ObjectReader.withAttribute(...)`)
>
> -+ Tatu +-
>
> ps. The case of "JSON in JSON" (or "XML in JSON" or generally "X in Y"
> for Jackson-supported formats X and Y) is sort of a long-term request
> that has never been properly addressed. Assuming I did not misread
> the use case here.
>

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/jackson-user/adb1b7d1-0ff2-44a4-814f-efa2db2d27a3n%40googlegroups.com.

Reply via email to