-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
ArC fixes for spec compatibility, round 10 #33523
Conversation
independent-projects/arc/runtime/src/main/java/io/quarkus/arc/impl/CurrentInterception.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not exactly happy about the recursive interception and deferred unproxyability error, but I suppose it's as good as it gets now (given that it's in strict mode only).
We need to solve this on spec/tck lvl and then we can remove these workarounds.
This comment has been minimized.
This comment has been minimized.
Ouch. I didn't see this test failing locally, because I still have the commit that fixes inheriting non- |
I added the fix for inheritance of non- |
This comment has been minimized.
This comment has been minimized.
For future references, I've created a TCK challenge for the recursive interception test and a CDI issue for deferring unproxyable bean error. |
Rebased and removed the commit that prevents recursive interception. |
independent-projects/arc/runtime/src/main/java/io/quarkus/arc/InstanceHandle.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
This means that it delegates to `destroy()` not only for `@Dependent` beans, but for all beans. To avoid breaking existing users, this is only done in the strict mode.
Class-level interceptor bindings declared on a superclass should only be taken into account when they are `@Inherited`. ArC however inherits all interceptor bindings from superclasses, even if they are _not_ declared `@Inherited`. This commit fixes that in the strict mode, to not affect Quarkus security (which assumes that security annotations are inherited, even if they are not). Method-level annotations are never inherited. This means that the lowest override of a method determines whether method-level interceptor binding annotations are present. ArC used to behave differently. If a method on a class had no interceptor binding annotations but overrode a method from a superclass that _did_ have interceptor binding annotations, the method-level annotations from the superclass were inherited. This commit fixes that.
The CDI specification demands that if an injection point resolves to a bean, unproxyability of that bean should be treated as a deployment problem. ArC used to treat all unproxyable beans uniformly, even those that are not injected anywhere. This commit changes that: in strict mode, only unproxyable beans that are actually injected somewhere trigger a deployment-time error. Unproxyable beans that are not injected anywhere do not cause a deployment-time error and instead, the `Bean` class (its `get(CreationalContext)` method, specifically) is generated in a way that `UnproxyableResolutionException` is thrown when obtaining a contextual reference, as expected by the CDI spec.
This comment has been minimized.
This comment has been minimized.
✔️ 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. |
Related to #28558
InstanceHandle.close()
to behave as specified in strict mode@Inherited
class-level interceptor bindings, but only in strict mode, because Quarkus expects security annotations to be inherited even though they are not@Inherited
With these changes, the only remaining TCK exclusions are tests that have been challenged. With an upcoming release of CDI TCK 4.0.10, we'll pass the entire CDI Lite TCK (with exactly 1 exclusion for a challenged test) 🎉