-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excluding exception mappers in the Arc results in NoSuchMethodException
#29403
Comments
Hi Ivan, Have you tried to exclude it with class path in application.properties as it is described here Like : |
If you exclude the exception mapper class via To be honest, I'm not quite sure this is a supported use case. |
Yeah, I wouldn't say this is really supported. |
I want to have the generic mappers in a common-project. But then let anybody use that commons project and avoid having predefined mappers and create their own. Can I can control mapper inclusion with a property, for example:
Or is there any other way to conditionally register an exception mapper? |
That's what I thought. In that case, this looks like a duplicate of #29115, do you agree? With Quarkus |
It looks like adding support for |
…n methods Although we can make this work in the future, it involves a fair amount of work for a very small gain, so let's make it explicit for now that this combination is not allowed. Follows up on: quarkusio#29118 Relates to: quarkusio#29403
What about @LookupIfProperty, would this be easier? |
I have actually never used Unfortunately no, it would not make things any easier |
OK, but I still assume that if I move the exception mappers to JAX-RS style with |
Ah damn it... I thought we were talking about filters here, 🤦🏼 . It does seem like we'll need to do the same thing for exception mappers as the combination of annotation is currently not supported. You can't have a producer method for JAX-RS style exception mappers, they aren't registered like that. |
After looking at this, I have concluded that we will need a smarter way of handling both the filters and exception mappers case. I need to sleep on how that can be done |
#29459 takes care of the issue |
Any idea when #29459 will be merged and in what version can we expect the fix? |
It will be part of |
Take conditional annotation into account for @ServerExceptionMapper
But wait this now only throws the build exception if the annotations are combined? There is still no support for this?
|
You can't use |
Ahh, OK let me try this :) |
Are we good to close this now? |
Definitely |
Great, thanks |
Describe the bug
When a dependency defines exception mappers, the exclusion using the
-Dquarkus.arc.exclude-types
does not work. Even worse, it's ending up in theNoSuchMethodException
.The exception mapper is defined as:
Exclusions that we tried:
-Dquarkus.arc.exclude-types=io.stargate.sgv2.api.common.exception.*
-Dquarkus.arc.exclude-types=io.stargate.sgv2.api.common.exception.**
Stack trace below:
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.13.4.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: