Issue 3753 - CDI2 doesn't work with BeanValidation

[pa314159]

Caused by SuplierBeanBridge returning the same bean ID for all bindings.

Updated getBeanClass to return the contract class, making the bean ID
to relate to the actual type.

Signed-off-by: pa314159 [email protected]

[mkarg]

@jansupol I tried it out just now, and this PR actually solves #4208. It would be really, really great if you could merge it into 2.29.1 🙏

[mkarg]

I confirm this solves #4208.

[pa314159]

Unfortunately I found another issue with injection by @context in InjectingConstraintValidatorFactory. :(

I'll try to figure out what is going on in cdi2-se.

[jansupol]

This PR seems to break HelloWorldTest.testHello

[mkarg]

@pa314159 Can you please fix the failing test?

[pa314159]

@mkarg, @jansupol, pushing that test was on purpose, it's should be fixed now.

I have no clue why @context injection doesn't work in InjectingConstraintValidatorFactory - @Inject works, but that's normal.

I ended up by instantianting InjectingConstraintValidatorFactory directly, I don't see any reason to be a CDI bean.

[mkarg]

@jansupol How to proceed?

[jansupol]

There is a couple of issues here:

1. @Context SecurityContext does not work
2. BV @NotNull does not work
3. @Context ResourceContext resourceContext does not work
4. Hello World is enriched by BV
5. Fix this before 2.29.1

For 1 - 3 @senivam was anxious to look at that in more detail. Nevertheless, I would think {1} and {2,3} would be better to have a separate issue (PRs) for them. For 4, I am not sure a new example would be better. Maybe not. For 5, hopefully, it will be done.

[mkarg]

@jansupol Thanks a lot for the triage! I share your view.
@senivam Thank you for looking into that! The fix will be really appreciated! 🎉

[pa314159]

@jansupol thanks for clarification. I confirm that neither @NotNull nor any other validation works.

[mkarg]

@pa314159 Can you please split the PRs as prposed by @jansupol?

[pa314159]

@mkarg sure, but what exactly want me to do?

The correction of SuplierBeanBridge solves the CCE reported by #4208 and the ILA reported by #3753. On the other hand, to have a working validation with CDI2, more work is required, just solving the ILA wasn't enough.

So, how to proceed?

[mkarg]

The correction of SuplierBeanBridge solves the CCE reported by #4208 and the ILA reported by #3753. On the other hand, to have a working validation with CDI2, more work is required, just solving the ILA wasn't enough.

Please open a PR that clearly describes what it solely is good for and that only covers #4208 but not any other bug. We need this rather soon as this bug and only this bug is planned for inclusion in 2.29.1.

Plese open a PR that clearly describes what it solely is good for and that only covers the actually fixed parts of #3753 but not any other bug as this bug is not planned for inclusion in 2.29.1.

...and so. Just to enable Team Jersey to understand what each single fix is good for and to pick each bug fix separately. I know this looks like nitpickery as we certainly could simply cherry-pick the commits separately. But first, this is not how the contribution process works - Team Jersey (and I assume most EE4J teams) picks complete PRs only - and second this could end up in your authorship information getting lost by rewriting commits (e. g. if I would separate your PRs, my name could be shown instead of yours). So we hope you understand why we need this clear process. To speed things up, I could open a PR and cherry-pick the urgent commits, just tell me if you like to go with that.

Thanks a lot! :-)
-Markus

[pa314159]

OK, I agree of the need of traceability and awareness :)

So this is what I did: I created PR #4236, where getBeanClass is implemented in SupplierBeanBridge and I related it to issue #4208.

There is only one commit that is relevant for both #3753 and #4236.

In this case, although it solves the ILA, it doesn't solve the whole BV validation. You will need to decide what to do with #3753, because the title and the description won't match anymore after merging changes from #4236.

[pa314159]

@mkarg, meanwhile I've made the bean validation work, but that needs the changes from #4236.

I'll wait for that PR to get merged and I'll create a new PR afterwards...

[mkarg]

@pa314159 This is no problem. You can open a separate PR right now with both commits as a sequence, but keep it in the draft state (i. e. switch the PR-creation-button's mode from PR to draft), which effectively prevents the merge. Once #4236 is merged, you simply rebase on master , push with -f flag, and switch the PR from draft mode to ready for merge. :-)