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

Introduce Preprocessor #6057

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Introduce Preprocessor #6057

wants to merge 5 commits into from

Conversation

jrhee17
Copy link
Contributor

@jrhee17 jrhee17 commented Jan 8, 2025

Motivation:

This PR introduces the notion of Preprocessors and allows users to configure these to clients as options.
The second part of this PR will introduce a way for users to solely create a client based on Preprocessors. The eventual POC can be found here: https://github.com/jrhee17/armeria/pull/36/files

Eventually this extension point will also make it easier/clearer for users to use xDS with existing Armeria APIs.

The full capability/limitations/design of Preprocessors are better described in the following PR: #6051

Modifications:

  • Introduced Preprocessor and PreClient APIs
  • Added ClientPreprocessors and ClientPreprocessorsBuilder to allow users to easily add Preprocessors to clients as options
  • Modified DefaultWebClient, DefaultTHttpClient, and ArmeriaClientCall to use Preprocessors
  • In order to allow users a way to overwrite the chosen EndpointGroup, the EndpointGroup is now specified when creating a ClientRequestContext instead of at initialization time.
  • Modified ClientUtil methods to pass an additional req field which signifies the original request for type-safety.

Result:

  • Users can specify Preprocessors when creating a client.

@jrhee17 jrhee17 added this to the 1.32.0 milestone Jan 8, 2025
@jrhee17 jrhee17 marked this pull request as ready for review January 8, 2025 04:58
BiFunction<ClientRequestContext, Throwable, O> errorResponseFactory) {
final ClientRequestContextExtension ctxExt = ctx.as(ClientRequestContextExtension.class);
if (ctxExt != null) {
ctxExt.runContextCustomizer();
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

Copy link
Contributor

@ikhoon ikhoon left a comment

Choose a reason for hiding this comment

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

Nice work! 👍🚀

@ikhoon
Copy link
Contributor

ikhoon commented Jan 10, 2025

@minwoox Do you have time to review this?

Copy link
Contributor

@minwoox minwoox left a comment

Choose a reason for hiding this comment

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

Left some minor comments but looks good all in all. 👍

/**
* Sets the {@link EndpointGroup} used for the current {@link Request}.
*/
void endpointGroup(EndpointGroup endpointGroup);
Copy link
Contributor

Choose a reason for hiding this comment

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

setEndpointGroup?

We usually name the method in ClientRequestContext as setX when a getter of the X exists.

@@ -83,7 +74,6 @@ protected UserClient(ClientBuilderParams params, Client<I, O> delegate, MeterReg
BiFunction<ClientRequestContext, Throwable, O> errorResponseFactory) {
super(delegate);
this.params = params;
this.meterRegistry = meterRegistry;
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you remove this from the parameters?
Also, could you update HttpClientFactory.setMeterRegistry if you don't want to use this meter?

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've just reverted to use HttpClientFactory.setMeterRegistry for backwards compatibility

* The context customizer must be run before the following conditions.
* <li>
* <ul>
* EndpointSelector.select() so that the customizer can inject the attributes which may be
Copy link
Contributor

Choose a reason for hiding this comment

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

Please insert {@link ...}.

@@ -113,12 +120,9 @@ public HttpResponse execute(HttpRequest req, RequestOptions requestOptions) {
newReq = req.withHeaders(req.headers().toBuilder().path(newPath));
}

return execute(protocol,
Copy link
Contributor

Choose a reason for hiding this comment

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

Would you add @Deprecated annotation to the execute methods?

Copy link
Contributor

@minwoox minwoox left a comment

Choose a reason for hiding this comment

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

Way to go! 👍 🎉 👍

* illustrates a sample use-case:
* <pre>{@code
* HttpPreprocessor preprocessor = (delegate, ctx, req) -> {
* ctx.endpointGroup(Endpoint.of("overriding-host"));
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* ctx.endpointGroup(Endpoint.of("overriding-host"));
* ctx.setEndpointGroup(Endpoint.of("overriding-host"));

* illustrates a sample use-case:
* <pre>{@code
* RpcPreprocessor preprocessor = (delegate, ctx, req) -> {
* ctx.endpointGroup(Endpoint.of("overriding-host"));
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* ctx.endpointGroup(Endpoint.of("overriding-host"));
* ctx.setEndpointGroup(Endpoint.of("overriding-host"));

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.

3 participants