You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Throwing a RuntimeException when an invalid XML body gets deserialized by JAXB makes exception handling difficult using the ExceptionMapper mechanism.
Implementation ideas
Create a new exception, dedicated to JAXB deserialization errors, that wraps the UnmarshalException. Then it would be possible to handle that exception cleanly in a dedicated ExceptionMapper.
The text was updated successfully, but these errors were encountered:
davidreis97
changed the title
Avoid throwing a RuntimeException when XML parsing using JAXB throws a jakarta.xml.bind.UnmarshalException
Avoid throwing a RuntimeException when parsing an invalid XML body using JAXB
Mar 12, 2024
I compared the implementations of ServerJaxbMessageBodyReader to the json equivalent ServerJacksonMessageBodyReader and there, if the deserialization fails, a WebApplicationException is thrown.
Would that work for Jaxb also? I'd assume the same result: Bad Request would be a good default here also.
But the same way as in the jackson, the exceptions related to the configuration of the deserialization should be separated and thrown as runtime exceptions resulting in Internal Server Error.
Based on my tests in the Draft PR I noticed that the resteasy-reactive-jaxb and resteasy-jaxb behave differently. The reactive implementation returns 500 when an invalid xml is sent and the other one returns 400. My suggestion is that resteasy-reactive-jaxb would be modified to work like resteasy-reactive-jackson works when invalid json is sent -> WebApplicationException resulting in http 400.
I could go on and try to fix it if this sounds like a plan? I would also need to add an integration test module as I have done in the pr to bring up the issue and verify the fix.
Description
Throwing a RuntimeException when an invalid XML body gets deserialized by JAXB makes exception handling difficult using the ExceptionMapper mechanism.
Implementation ideas
Create a new exception, dedicated to JAXB deserialization errors, that wraps the UnmarshalException. Then it would be possible to handle that exception cleanly in a dedicated ExceptionMapper.
The text was updated successfully, but these errors were encountered: