-
Notifications
You must be signed in to change notification settings - Fork 467
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
Weld Container should auto detect any annotated bean #30187
Comments
fabrizzio-dotCMS
moved this from Next 1-3 Sprints
to Current Sprint Backlog
in dotCMS - Product Planning
Oct 9, 2024
fabrizzio-dotCMS
moved this from Current Sprint Backlog
to In Progress
in dotCMS - Product Planning
Oct 9, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 29, 2024
### Proposed Changes * Jersey 2.28 works with CDI1.x * beans.xml were downgraded to use CDI 1.x * A Few "Producer" classes were removed as they were generating conflicts trying to decide what implementation had to be chosen * Updated the Resources where there were previous attempts to introduce injection * Some classes were located in different projects but had identical names like GenericBundleActivatorTest Weld didn't like that so I had to rename one of them. * CDI Utils has a new method that throws an exception as some people complained about the one returning an Optional * We have support for Integration tests through these two runners (JUnit4WeldRunner,DataProviderWeldRunner) * If we want to use CDI2.x we will have to wait until we move to tomcat 10+
github-project-automation
bot
moved this from In Review
to Internal QA
in dotCMS - Product Planning
Oct 29, 2024
We need to inform #eng on this... maybe the wiki page?
|
spbolton
pushed a commit
that referenced
this issue
Nov 11, 2024
### Proposed Changes * Jersey 2.28 works with CDI1.x * beans.xml were downgraded to use CDI 1.x * A Few "Producer" classes were removed as they were generating conflicts trying to decide what implementation had to be chosen * Updated the Resources where there were previous attempts to introduce injection * Some classes were located in different projects but had identical names like GenericBundleActivatorTest Weld didn't like that so I had to rename one of them. * CDI Utils has a new method that throws an exception as some people complained about the one returning an Optional * We have support for Integration tests through these two runners (JUnit4WeldRunner,DataProviderWeldRunner) * If we want to use CDI2.x we will have to wait until we move to tomcat 10+
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Parent Issue
#29552
Task
We have enabled CDI through #29552
Currently, we depend on the CDIUtils to create an entry point to instantiate all Annotated Beans
But we have run into a case that must be supported. Let's say we have a @Inject into a resource
DotRestApplication must be capable of detecting any annotated bean and taking care of the injection itself
Therefore we need to iterate over this once again and solve this problem
Proposed Objective
Same as Parent Issue
Proposed Priority
Same as Parent Issue
Acceptance Criteria
Any Resource discovered by DotRestApplication containing a @Inject must be capable of finding and injecting any Beans annotated with @ApplicationScope
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
No response
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response
The text was updated successfully, but these errors were encountered: