-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Produce EventLoopGroup build item #33239
Produce EventLoopGroup build item #33239
Conversation
@cescoffier could you take a look at this one? |
42a4bce
to
a896727
Compare
There is already a |
@cescoffier If no |
Ah, I see. This must be added in the javadoc, as it's a bit confusing to have two very similar build items. |
Already put some explanations on both build items. Would you mind help me rephrase to make it clearer ? |
a896727
to
db3f80b
Compare
This comment has been minimized.
This comment has been minimized.
@cescoffier friendly ping :) |
@cescoffier friendly ping :) It would be great if it could be merged for 3.1. I'd like to refactor AWS extension to use the same event loop. I have made some commits to the AWS sdk and it is now possible to configure most of the used ThreadPool and EventLoop. I just need this PR to complete the work in AWS extension. |
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.
Sorry for the delay, the last few weeks got chaotic.
Can you rebase to have another ci run? |
db3f80b
to
f032a0b
Compare
Allow other extensions to reuse the EventLoopGroup that is effectively used without making assumptions on the presence of Vert.x extension.
As a non-CDI expert, I'm not sure if there's a better way to expose those suppliers. Consumers would implement a build step as follows:
The drawback is that supplier must return a singleton since it can be called multiple times.