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

Make sure bean params are @Typed correctly for CDI lookup in case of subtyping #29355

Merged
merged 1 commit into from
Nov 24, 2022

Conversation

FroMage
Copy link
Member

@FroMage FroMage commented Nov 18, 2022

Fixes #29227

Copy link
Contributor

@manovotn manovotn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one small comment, otherwise looks good.

// check if the class is a bean param
if (beanParams.contains(clazz.name().toString())
&& clazz.declaredAnnotation(ResteasyReactiveDotNames.TYPED) == null) {
// Stef: we could use createTypedAnnotationInstance which adds all interfaces but I don't think
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use it for the sake of consistency and future debugging :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But why would we want to produce the interfaces as beans? Won't that lead to potential ambiguous issues like the one we want to fix? Also, bean params are only ever injected as their declared type by RESTEasy Reactive: never as interfaces. I understand the consistency issue you raise, but I felt this would introduce broadness that could lead into future bugs, and would rather have restricted this fix to what we know we absolutely require, and add the interfaces later if and when there's a use-case for them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, the impl I added didn't have interfaces and kept just the impl class and that worked fine for RR and for our tests.
But the issue that made me add it (#29128) shows that user can leverage these classes as beans in various ways that we didn't anticipate. I would generally say that fiddling with types of beans without user knowledge is risky as you might break their injection logic. So the more types you can keep there, the better. It's not like we need to do some extra legwork to make it work either.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, whatever. Lemme try.

@quarkus-bot

This comment has been minimized.


@Test
void shouldDeployWithoutIssues() {
// we only need to check that it deploys
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FroMage you could also check that the bean has all the expected types, see ResourceBeanTypeTest as an example.
But I won't insist :)

@gsmet
Copy link
Member

gsmet commented Nov 24, 2022

@manovotn is this one good enough for you (I think we can improve the test later if needed)? I would like to get this one into 2.14.2.Final.

@manovotn
Copy link
Contributor

@gsmet I didn't mean to block it, feel free to go ahead with it :)

@manovotn manovotn merged commit 25c695d into quarkusio:main Nov 24, 2022
@quarkus-bot quarkus-bot bot added this to the 2.15 - main milestone Nov 24, 2022
@gsmet gsmet modified the milestones: 2.15 - main, 2.14.2.Final Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrading to 2.14 breaks REST resources (potentially because of BeanParam)
3 participants