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

Fixes #12348 - HttpClientTransportDynamic does not initialize low-level clients. #12349

Merged

Conversation

sbordet
Copy link
Contributor

@sbordet sbordet commented Oct 4, 2024

Fixed initialization for HTTP/2 and HTTP/3.

…el clients.

Fixed initialization for HTTP/2 and HTTP/3.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet requested a review from lorban October 4, 2024 16:25
@sbordet sbordet linked an issue Oct 4, 2024 that may be closed by this pull request
Comment on lines 1152 to 1154
* <p>Implementations of this interface are made aware of
* the {@code HttpClient} instance while it is starting.</p>
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

Need more info than this. Implementations of this interface that are: set as beans? added as listeners? discovered through ServiceLoader???

I think it should be on all beans (see below)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why? There is no need to do that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Because Aware is an interface on HttpClient. It looks like a general mechanism, not something just for some transport factories. If it is just for transport factories, then makes it a sub interface of transport factories.

You don't know that transport factories needed this until now, so why not just make it general and any bean added to the client can be aware.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have the opposite stance: I don't want to make it a generic mechanism when it is only needed in one case.
We can always make it generic, if we really need to, in the future.

It cannot be made part of ClientConnectionFactory because it's in jetty-io, while awareness is in jetty-client.

Copy link
Contributor

@gregw gregw Oct 5, 2024

Choose a reason for hiding this comment

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

But it is already generic. There is nothing in the name, signature nor javadoc of HttpClient.Aware that says it is not generic and doesn't apply widely.

It is only in the implementation that it is only applied to infos... and I had to look up the code again to see that infos are ClientConnectionFactories.

So you have a generic interface that is not implemented generically and I have to do two dereferences into the implementation to know that.

It is simpler in naming, easier to explain and LESS CODE just to make it generic on all beans rather than specific to just one component.

If you want to keep it like this, then it needs to be renamed to AwareClientConnectionFactory.

Comment on lines 137 to 140
infos.stream()
.filter(info -> info instanceof HttpClient.Aware)
.map(HttpClient.Aware.class::cast)
.forEach(info -> info.setHttpClient(getHttpClient()));
Copy link
Contributor

Choose a reason for hiding this comment

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

infos is an insufficient name. I have to go find its type to understand the code. How about just being verbose clientConnectionFactoryInfos

However, as all the infos are beans anyway, why not look for any contained Aware bean and save some code:

Suggested change
infos.stream()
.filter(info -> info instanceof HttpClient.Aware)
.map(HttpClient.Aware.class::cast)
.forEach(info -> info.setHttpClient(getHttpClient()));
getContainedBeans(Aware.class).forEach(a -> a.setHttpClient(client));

Copy link
Contributor

Choose a reason for hiding this comment

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

actuallyu, as getContainerBeans walks the containment tree, you don't have to do this at every level. You can just do this one at the top level and find all Aware components under HttpClient

Copy link
Contributor Author

Choose a reason for hiding this comment

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

infos is an insufficient name. I have to go find its type to understand the code. How about just being verbose clientConnectionFactoryInfos

Why? It is already called ClientConnectionFactory.Info.
We don't duplicate the name of the outer class into inner classes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not suggesting changing the name of the type, only the variable

public void setHttpClient(HttpClient httpClient)
{
ClientConnectionFactoryOverHTTP2 factory = (ClientConnectionFactoryOverHTTP2)getClientConnectionFactory();
factory.setHttpClient(httpClient);
Copy link
Contributor

Choose a reason for hiding this comment

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

should be set on all beans

Comment on lines 1152 to 1154
* <p>Implementations of this interface are made aware of
* the {@code HttpClient} instance while it is starting.</p>
*/
Copy link
Contributor

Choose a reason for hiding this comment

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

Because Aware is an interface on HttpClient. It looks like a general mechanism, not something just for some transport factories. If it is just for transport factories, then makes it a sub interface of transport factories.

You don't know that transport factories needed this until now, so why not just make it general and any bean added to the client can be aware.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet requested a review from gregw October 6, 2024 13:49
gregw
gregw previously approved these changes Oct 6, 2024
@sbordet sbordet requested a review from lorban October 7, 2024 13:24
lorban
lorban previously approved these changes Oct 8, 2024
Copy link
Contributor

@lorban lorban left a comment

Choose a reason for hiding this comment

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

Add a test for the LinkedHashMap change then LGTM.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet dismissed stale reviews from lorban and gregw via 93107a7 October 8, 2024 16:22
@sbordet
Copy link
Contributor Author

sbordet commented Oct 8, 2024

After discussion with @lorban, we removed text hinting at ordering from getContainedBeans(Class) javadocs.
The removed text was saying the order was depth-first, but the implementation was actually breadth-first.
However, we kept LinkedHashSet just in case ordering would be important in the future.

@sbordet sbordet merged commit f2c70fb into jetty-12.0.x Oct 10, 2024
6 of 9 checks passed
@sbordet sbordet deleted the fix/jetty-12.0.x/12348/httpclienttransportdynamic-config branch October 10, 2024 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

HttpClientTransportDynamic does not initialize low-level clients
3 participants