-
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
ArC fixes for spec compatibility, round 4 #31248
Conversation
This comment has been minimized.
This comment has been minimized.
extensions/arc/deployment/src/main/java/io/quarkus/arc/deployment/BeanArchiveProcessor.java
Show resolved
Hide resolved
...projects/arc/tests/src/test/java/io/quarkus/arc/test/injection/order/InjectionOrderTest.java
Show resolved
Hide resolved
independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/Injection.java
Outdated
Show resolved
Hide resolved
independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/Injection.java
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
The CI failures look related:
|
Yeah. I'll look. |
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 only have two minor comments.
Many thanks for diving into the AtInject TCKs :)
extensions/arc/deployment/src/main/java/io/quarkus/arc/deployment/BeanArchiveProcessor.java
Show resolved
Hide resolved
independent-projects/arc/processor/src/main/java/io/quarkus/arc/processor/Injection.java
Show resolved
Hide resolved
The test failure shows exactly why I was originally hesitant to change |
In case of class beans, dependency injection order is specified by the AtInject specification as follows: - injection points on superclasses are injected before injection points on subclasses; - fields are injected before initializer methods. Since we discover injection points bottom up, this requires reordering after each class in the hierarchy is scanned for injection points. The specification also prescribes that overridden initializer methods are not injected at all. Since we discover injection points bottom up, this requires remembering already seen methods and skipping methods that are overridden by those that were previously seen. This requires proper override detection. The `Methods.isOverridden()` and `Methods.MethodKey` utils are not enough, because they actually do _not_ detect overrides. They are used to skip processing a method in case a method with the same signature has already been processed. To do detect overridden methods properly, it is important to remember that: - private methods cannot be overridden, - package-private methods can only be overridden in the same package. For that reason, this commit introduces a dedicated override detection utility.
I have no idea what the failure means -- the Windows job probably ran a lot later than the other jobs and the cached Maven repo .zip was no longer available? 🤔 |
I've seen that before but don't know the cause either. |
Related to #28558
@Inject
, similarly to static fieldsBeanGenerator
changes, I suggest to hide whitespace changesbeans.xml
withbean-discovery-mode="none"
are no longer treated as bean archives