-
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
Cache: fix CacheInterceptor in case of non-ArC interceptor bindings #43832
Conversation
RESTEasy Classic's MP RestClient implementation produces annotations at runtime, so they are not created by ArC and therefore don't extend `AbstractAnnotationLiteral`. At the same time, that implementation produces an `ArcInvocationContext` and puts interceptor bindings into its context map under the ArC key. Some places may expect that an `ArcInvocationContext` would always contain ArC-created `AbstractAnnotationLiteral` instances, but alas, per the description above, that is not the case. There are multiple options for fixing that collision. My preferred one would be to get rid of `AbstractAnnotationLiteral` and treat all annotations uniformly. That unfortunately has negative performance implications on the `CacheInterceptor`, so is not an option yet [1]. This commit chooses another path: it modifies the only place in Quarkus that actually depends on `AbstractAnnotationLiteral` to check whether the `Set<AbstractAnnotationLiteral>` actually contains instances of `AbstractAnnotationLiteral`. I hope that before more places in Quarkus start depending on `AbstractAnnotationLiteral`, we can get rid of it. This commit only checks the first annotation in the set, because if the bindings come from RESTEasy Classic, then none of them are instances of `AbstractAnnotationLiteral`, and if they come from ArC, then all of them are instances of `AbstractAnnotationLiteral`. [1] The performance issue (JDK-8180450) is fixed in JDK 23 and has not been backported to any LTS release as of this writing.
For the record, it worked in Quarkus 3.3.3 because there was no |
Status for workflow
|
RESTEasy Classic's MP RestClient implementation produces annotations at runtime, so they are not created by ArC and therefore don't extend
AbstractAnnotationLiteral
. At the same time, that implementation produces anArcInvocationContext
and puts interceptor bindings into its context map under the ArC key.Some places may expect that an
ArcInvocationContext
would always contain ArC-createdAbstractAnnotationLiteral
instances, but alas, per the description above, that is not the case.There are multiple options for fixing that collision. My preferred one would be to get rid of
AbstractAnnotationLiteral
and treat all annotations uniformly. That unfortunately has negative performance implications on theCacheInterceptor
, so is not an option yet [1].This commit chooses another path: it modifies the only place in Quarkus that actually depends on
AbstractAnnotationLiteral
to check whether theSet<AbstractAnnotationLiteral>
actually contains instances ofAbstractAnnotationLiteral
. I hope that before more places in Quarkus start depending onAbstractAnnotationLiteral
, we can get rid of it.This commit only checks the first annotation in the set, because if the bindings come from RESTEasy Classic, then none of them are instances of
AbstractAnnotationLiteral
, and if they come from ArC, then all of them are instances ofAbstractAnnotationLiteral
.[1] The performance issue (JDK-8180450) is fixed in JDK 23 and has
not been backported to any LTS release as of this writing.
Fixes #36336