Allow ConstraintViolationException to not cause JsonMappingException.

[soberich]

@cowtowncoder
I have implemented JavaAgent (with ByteBuddy) which transforms classes to support executable validation for methods and constructors parametres on non-CDI beans (but just plain POJOs) as a result when a REST endpoint receives body and tries to deserialize JSON to Object using setter or constructor
(for example)

public void setFrom(@javax.validation.NotNull String from) {
    // ...
}

if constraint violation occur, I got ..

Caused by: com.fasterxml.jackson.databind.JsonMappingException: N/A
 at [Source: io.undertow.servlet.spec.ServletInputStreamImpl@60b31f1e; line: 1, column: 10] (through reference chain: com.example.Person["from"])
	at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:277)
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty._throwAsIOE(SettableBeanProperty.java:551)
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty._throwAsIOE(SettableBeanProperty.java:532)
	at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:108)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:276)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:140)
	at com.fasterxml.jackson.databind.ObjectReader._bind(ObjectReader.java:1583)
	at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:964)
	at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.readFrom(ResteasyJackson2Provider.java:134)
	at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:66)
	at org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:61)
	at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:56)
	at org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:36)
	at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:59)
	at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:151)
	... 49 more
Caused by: javax.validation.ConstraintViolationException
	at com.example.Person.setFrom(Person.java:28)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:106)
	... 60 more

So it sees ConstraintViolationException but wraps it with JsonMappingException obviously.
How to tell Jackson to not to throw JsonMappingException if the cause is ConstraintViolationException?
Is it possible to allow jackson to Unwrap / Do Not Wrap the cause it?
Hibernate Validator framework will, as well implement and provide default implementation of Executable Validation (maybe even in 6.x version soon). They already started to implement here are the starters, so the problem will occur as well.

P.S. Maybe it is worth to just allow for the whole library overall to check if the cause is ConstraintViolationException and rethrow if so ?

I use version 2.9.5 (and 2.8.9 - which behaves the same)

[cowtowncoder]

@soberich It is possible to disable exception wrapping (for cases where possible) using WRAP_EXCEPTIONS for both DeserializationFeature and SerializationFeature. That applies to all RuntimeExceptions; by default IOExceptions are not wrapped by default.

I don't think I want to start adding specialized handling for all potential subtypes of RuntimeException.
It could be possible to consider some sort of pluggable handler that could determine what to do (not wrap; wrap with some other legal exception), although that would need to be for Jackson 3.0.

One thing to consider is that many libraries and frameworks wrap exceptions, so calling code tends to have ability to "unwrap" exceptions to find root causes. That may be better way to go here.

[cowtowncoder]

Not quite sure how to proceed with this, closing: may be reopened with more concrete proposal (like proposing some sort of handler to decide whether to wrap an exception(s) of some type).