Open nlenoire opened 5 months ago
Does this rely on something wrt JAX-RS provider? Looks like test is trying to isolate reproduction; and if that is possible we could move this to jackson-databind
and it'd be much easier to troubleshoot?
But I wanted to ask before transferring.
Does this rely on something wrt JAX-RS provider? Looks like test is trying to isolate reproduction; and if that is possible we could move this to
jackson-databind
and it'd be much easier to troubleshoot? But I wanted to ask before transferring.
Yes, it is related to the JAX-RS provider. In a JAX-RS runtime we face this issue and the above test simulate a reproduction env. This only occurs with the JAX-RS provider, not with plain ObjectMapper.
However, if you think it's better to move it to the jackson-databind
, no problem.
Can/should only move if it reproduction is possible without JAX-RS dependencies. Sounds like it is not; if so, need to stay here.
However... I am not really sure what could be done here -- sounds like ObjectMapper
configuration problem?
However... I am not really sure what could be done here -- sounds like
ObjectMapper
configuration problem?
@cowtowncoder I'm not sure to understand what do you mean. Arn't we injecting a properly configured ObjectMapper
into a JacksonJsonProvider
? Can't we expect that object mapper and its configuration to be used for deserialization?
Ok, so this is not necessarily about FAIL_ON_UNRESOLVED_OBJECT
but in general ensuring specific ObjectMapper
is being used. And that would be something Provider should guarantee.
Hello,
It seems we are facing an issue with JacksonJsonProvider that silently ignores
DeserializationFeature.FAIL_ON_UNRESOLVED_OBJECT_IDS
set on the ObjectMapper.The following test case reproduces the issue:
Thanks for your help.