Allows users to exclude DefaultMismatchedInputException

[geoand]

A few users have run into an issue where
they are trying to handle all Jackson exceptions
but the existence of DefaultMismatchedInputException
prevents that for MismatchedInputException
(as per JAX-RS / Jakarta REST rules).

This change allows users to do use:

quarkus.class-loading.removed-resources."io.quarkus\:quarkus-rest-jackson"=io/quarkus/resteasy/reactive/jackson/runtime/mappers/DefaultMismatchedInputException.class

in order to have Quarkus ignore the mapper.

P.S. We could also introduce a specific property for this, but currently I am on the fence about that...

[github-actions]

🙈 The PR is closed and the preview is expired.

[gsmet]

Hmmm, I have a few comments here.

Should we rename the class to DefaultMismatchedInputExceptionMapper before documenting it somewhere? When I read the description, I thought it was an exception and had a hard time understanding the issue.

Second question: isn't it easier to create a mapper with a higher priority that specifically handles this exception instead of promoting a rather obscure feature?

And finally, I wonder if at some point, these dev modes features should be handled specifically after the exception mappers have been applied (and only be triggered if no ExceptionMapper handled the exception).

[geoand]

Should we rename the class to DefaultMismatchedInputExceptionMapper before documenting it somewhere? When I read the description, I thought it was an exception and had a hard time understanding the issue

How about BuiltinMismatchedInputExceptionMapper?

Second question: isn't it easier to create a mapper with a higher priority that specifically handles this exception instead of promoting a rather obscure feature?

That doesn't work (as per JAX-RS / Jakarta REST) when users want to handle a super class of MismatchedInputException.

And finally, I wonder if at some point, these dev modes features should be handled specifically after the exception mappers have been applied (and only be triggered if no ExceptionMapper handled the exception).

I don't really understand this, can you elaborate a little?

[gsmet]

How about BuiltinMismatchedInputExceptionMapper?

Looks good.

That doesn't work (as per JAX-RS / Jakarta REST) when users want to handle a super class of MismatchedInputException.

Maybe I wasn't clear but my understanding was that they would have to have a specific mapper for MismatchedInputException. I thought it might be easier to grasp from a user perspective.

But you can start your way and see how to make it easier to grasp later.

I don't really understand this, can you elaborate a little?

I think it's not the first time we have dev mode features in the way of how you would expect a standard JAX-RS implementation to work.
Typically this feature we have is nice in dev mode but I think it shouldn't be in the way when you customize things on your side.

Thus why I was wondering if we should have a way to enable these features only if something from the user didn't catch things earlier.

Basically, we should find a way for our mappers (or not implement them as mappers) to be very last resort if nothing else from the users intervened first.

[geoand]

Maybe I wasn't clear but my understanding was that they would have to have a specific mapper for MismatchedInputException. I thought it might be easier to grasp from a user perspective.

That would work today without any configuration. What does not work as users would like, is handling all exceptions that are super classes of this exception.

Basically, we should find a way for our mappers (or not implement them as mappers) to be very last resort if nothing else from the users intervened first.

Yeah, that would be nice, but unfortunately the resolution rules don't really allow this - hence the ability to remove this one.

I think it's not the first time we have dev mode features in the way of how you would expect a standard JAX-RS implementation to work.

Agreed, but it's also surprising when code exists in dev-mode and affects the behavior of the system to not exist in prod mode, so I am really not sure what the best solution is here.

[geoand]

PR updated

[gsmet]

I will handle the comment given I'm already on this subject, no need for you to context switch.

[gsmet]

Force pushed with the doc fix squashed!

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit e9cddc0.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit e9cddc0.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[geoand]

Thanks!