Skip to content
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

Bean autowiring is non-deterministic when multiple beans exist with no @Priority #6301

Closed
jamesnetherton opened this issue Jul 30, 2024 · 3 comments
Assignees
Labels
area/core bug Something isn't working
Milestone

Comments

@jamesnetherton
Copy link
Contributor

Bug description

Relates to #5464. The code changes for that feature assume that if there are multiple beans for a given type, that they will have an @Priority assigned, so that the desired bean is returned from registry lookups.

IMO this is only reliable for beans declared from user code. The majority of beans created by Quarkus extensions do not have any @Priority (AFAIK). E.g like DataSource beans.

Thus, when Camel attempts to do autowiring, it will potentially inject a 'random' bean into components, since there is no @Priority enforced.

@jamesnetherton jamesnetherton added the bug Something isn't working label Jul 30, 2024
@jamesnetherton jamesnetherton added this to the 3.14.0 milestone Jul 30, 2024
@zhfeng
Copy link
Contributor

zhfeng commented Jul 30, 2024

I don't see a simple way to change this behavior except to intrdouct a priority in quarkus-agroal like

quarkus.datasource."test".priority = 100

Default beans can optionally declare @jakarta.annotation.Priority. If there is no priority defined, @priority(0) is assumed. see https://quarkus.io/guides/cdi-reference#default_beans

@jamesnetherton
Copy link
Contributor Author

In theory the same problem could exist for other extensions where you can have multiple named configurations. Like Infinispan, MongoDB etc.

Maybe another option would be to check if all of the returned beans have the same priority. If they do, try to resolve the default bean for the type. E.g something like:

container.select(type, Default.Literal.INSTANCE);

And if that fails, just return null and leave it for the user to determine which bean is used in their route.

@zhfeng
Copy link
Contributor

zhfeng commented Jul 30, 2024

Thanks @jamesnetherton and let me try this at first.

@zhfeng zhfeng self-assigned this Jul 30, 2024
zhfeng added a commit to zhfeng/camel-quarkus that referenced this issue Jul 31, 2024
zhfeng added a commit to zhfeng/camel-quarkus that referenced this issue Jul 31, 2024
@zhfeng zhfeng closed this as completed in 91cb3a2 Jul 31, 2024
zhfeng added a commit to zhfeng/camel-quarkus that referenced this issue Jul 31, 2024
zhfeng added a commit to zhfeng/camel-quarkus that referenced this issue Aug 5, 2024
zhfeng added a commit to jboss-fuse/camel-quarkus that referenced this issue Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants