Add gRPC outbound gateway for client calls #10684

cppwfs · 2026-01-08T16:40:22Z

Implement GrpcOutboundGateway to bridge Spring Integration messaging with gRPC client invocations. This component supports four gRPC communication patterns:

Unary: single request/single response
Server streaming: single request/multiple responses
Client streaming: multiple requests/single response
Bidirectional streaming: multiple requests/multiple responses

The implementation includes two main components:

GrpcOutboundGateway: Extends AbstractReplyProducingMessageHandler to provide request-reply semantics for gRPC clients. Features configurable async timeout (defaults to 10 seconds) and automatic method type detection based on the gRPC MethodDescriptor.

The gateway automatically determines the invocation strategy: blocking calls for unary operations and reactive Flux-based responses for streaming operations. For streaming patterns, the component uses Project Reactor's Sinks.Many to bridge gRPC's StreamObserver callback model with Spring Integration's reactive message handling.

Build configuration updated to include necessary gRPC API dependencies for both compilation and testing. Reference documentation extended with examples demonstrating all four communication patterns and configuration options. What's New section updated to highlight this new feature.

Fixes #10622

artembilan

Missed reference to the respective issue: #10622.
From branch name to the Fixes: sentence in the commit message.

artembilan

This is good start.
Feel free to reach me offline for any clarifications.
Thank you!

build.gradle

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

src/reference/antora/modules/ROOT/pages/grpc.adoc

artembilan

Looks promising!
Thanks

build.gradle

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

artembilan · 2026-01-09T21:24:06Z

spring-integration-grpc/src/test/proto/single_hello.proto

+  // Sends a greeting
+  rpc SayHello(HelloRequest) returns (HelloReply) {}
+
+}


I think new line is still has to be in the end even in this file.

Was not addressed.

src/reference/antora/modules/ROOT/pages/grpc.adoc

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

artembilan

I think we are very close.
Probably after the next commit, I'll pull it for a local final review.
Thanks

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

artembilan · 2026-01-13T16:19:47Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+ */
+public class GrpcOutboundGateway extends AbstractReplyProducingMessageHandler {
+
+	private final FunctionExpression<Message<?>> defaultFunctionExpression = new FunctionExpression<>(


Why cannot we rely on the boolean methodNameExpressionSet instead?
And have this new FunctionExpression as default value for the methodNameExpression.

artembilan · 2026-01-13T16:21:06Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	}
+
+	@Override
+	protected void doInit() {


This is confusing method order.
I'd prefer to have setters just after constructor and then init methods.

artembilan · 2026-01-13T16:22:04Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	 * Set an {@link Expression} to resolve the gRPC method name at runtime.
+	 * <p>
+	 * If not provided, the gateway will auto-detect the method when the service
+	 * descriptor contains exactly one method.


Please, also mention here some way that the default expression is against GrpcHeaders.SERVICE_METHOD.

artembilan · 2026-01-13T16:23:15Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	}
+
+	/**
+	 * Set the method name of the gRPC method.


Some tautology is in this sentence:

Set the name of the gRPC method to call.

?

artembilan · 2026-01-13T17:42:31Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

 === Attribute Expressions

-Set the CloudEvents' attributes of `id`, `source`, `type`, `dataSchema`, and `subject` through SpEL expressions.
+Set the CloudEvents attributes of `id`, `source`, `type`, `dataSchema`, and `subject` through SpEL expressions.


Not sure what CloudEvents changes are doing in this PR, but that's OK.
How about to use a singular: Set the CloudEvent attributes ?
With plural it does not sound.

...org/springframework/integration/grpc/outbound/GrpcClientOutboundGatewayMultiMethodTests.java

artembilan · 2026-01-13T17:45:04Z

...rg/springframework/integration/grpc/outbound/GrpcClientOutboundGatewaySingleMethodTests.java

+		}
+
+		@Bean
+		ManagedChannel channel() {


Let's discuss. I'm unclear on the issue.

artembilan · 2026-01-13T17:52:26Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+** `Collection<RequestType>`
+** Single `RequestType` object
+
+Client streaming methods return a `Mono<ResponseType>` with the single aggregated response, while bidirectional streaming methods return a `Flux<ResponseType>` with multiple responses.


I don't think its correct to talk about an aggregation from the gateway perspective.
That is just gRPC prtocol nuance what exactly is returned for the client streaming call.
Not a fact that a single result is an aggregation of request.
Just summary?
I mean this sentence should be a bit generic and don't mislead end-users for something what our gateway doesn't do.

artembilan · 2026-01-13T18:10:29Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+    GrpcOutboundGateway gateway = new GrpcOutboundGateway(channel, TestHelloWorldGrpc.class);
+    // Method name determined from GrpcHeaders.SERVICE_METHOD header at runtime
+    gateway.setMethodNameExpression(new FunctionExpression<>(
+            msg -> msg.getHeaders().get(GrpcHeaders.SERVICE_METHOD, String.class)));


This is actually a default expression.
Please, consider to mention that in the first item where you talk about auto-detection.
And here use some other expression, e.g. payload.class.simpleName

Implement `GrpcOutboundGateway` to bridge Spring Integration messaging with gRPC client invocations. This component supports four gRPC communication patterns: - Unary: single request/single response - Server streaming: single request/multiple responses - Client streaming: multiple requests/single response - Bidirectional streaming: multiple requests/multiple responses The implementation includes two main components: `GrpcOutboundGateway`: Extends `AbstractReplyProducingMessageHandler` to provide request-reply semantics for gRPC clients. Features configurable async timeout (defaults to 10 seconds) and automatic method type detection based on the gRPC `MethodDescriptor`. The gateway automatically determines the invocation strategy: blocking calls for unary operations and reactive Flux-based responses for streaming operations. For streaming patterns, the component uses Project Reactor's `Sinks.Many` to bridge gRPC's `StreamObserver` callback model with Spring Integration's reactive message handling. Build configuration updated to include necessary gRPC API dependencies for both compilation and testing. Reference documentation extended with examples demonstrating all four communication patterns and configuration options. What's New section updated to highlight this new feature. Fixes spring-projects#10622

Simplify the `GrpcOutboundGateway` constructor to require only channel and service class, making method name configuration optional. The gateway now auto-detects the method name when the service descriptor contains exactly one method, improving developer experience for single-method services. Key changes: Constructor simplified from three parameters (channel, service class, method expression) to two (channel, service class). Method name can now be configured via `setMethodNameExpression()` setter or omitted entirely for auto-detection. CLIENT_STREAMING pattern now correctly returns `Mono` instead of `Flux`, reflecting gRPC semantics where multiple requests produce a single aggregated response. New `invokeClientStreaming()` method uses `Sinks.One` for proper single-value handling. Test suite expanded with `GrpcClientOutboundGatewaySingleMethodTests` demonstrating auto-detection capability. Existing tests reorganized into `GrpcClientOutboundGatewayMultiMethodTests` and enhanced with CLIENT_STREAMING verification. New test proto file added for single-method service testing. Documentation updated to reflect simplified API, auto-detection feature, and correct return types for each gRPC pattern. Method name configuration section added with examples for explicit, dynamic, and auto-detected scenarios. Fix grammar in the grpc adoc rebased

Implement runtime method name resolution in `GrpcOutboundGateway` to support flexible gRPC invocation patterns. The gateway now evaluates method names dynamically per request instead of at initialization. Key changes: * Replace static method resolution with per-request evaluation * Add `setMethodName` setter for literal method name configuration * Support `GrpcHeaders.SERVICE_METHOD` header for method specification * Extend client streaming to accept Mono, POJO, Stream, and Collection * Separate streaming methods (server vs bidirectional) into distinct handlers * Convert logger calls to lambda expressions for deferred evaluation * Add javadoc for request/response patterns by method type

* Simplify method name resolution by tracking whether the expression was explicitly set. This allows proper auto-detection when only one method exists in the service descriptor. * Reorder private methods to group related functionality together. Move `invokeBidirectionalStreaming()` before `invokeServerStreaming()` and relocate `getMethodDescriptor()` closer to the main handler method. * Add `@SuppressWarnings` for unavoidable unchecked casts and raw types in dynamic method invocation paths. * Update test configurations to use shared `TestInProcessConfiguration` and `@EnableIntegration` annotation. * Remove CloudEvents documentation update. * Update gRPC documentation to clarify method resolution behavior and change the Expression example to a SpelExpression vs. the default expression. * Add array payload support for gRPC streaming * Add test coverage for client streaming methods that accept array payloads. * The new test verifies that an array of `HelloRequest` objects can be passed to a CLIENT_STREAMING method and properly converted to a Flux for transmission.

artembilan

Great!
thank you !

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

artembilan · 2026-01-15T23:28:52Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	 * <ol>
+	 *   <li>Evaluates the {@code methodNameExpression} to determine which gRPC method to invoke.
+	 *       The method name can be resolved from the message headers (via {@link org.springframework.integration.grpc.GrpcHeaders#SERVICE_METHOD}),
+	 *       a literal expression, or a custom expression.</li>


Was not addressed

artembilan · 2026-01-15T23:29:03Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	 *   <li><b>Client Streaming:</b> Returns a {@link Mono} with the single response</li>
+	 *   <li><b>Bidirectional Streaming:</b> Returns a {@link Flux} of response messages</li>
+	 * </ul>
+	 * @param requestMessage the message containing the gRPC request payload. The payload type depends on the


...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

...rg/springframework/integration/grpc/outbound/GrpcClientOutboundGatewaySingleMethodTests.java

...org/springframework/integration/grpc/outbound/GrpcClientOutboundGatewayMultiMethodTests.java

...rg/springframework/integration/grpc/outbound/GrpcClientOutboundGatewaySingleMethodTests.java

* Change UNARY gRPC invocations from blocking `blockingUnaryCall()` to async `asyncUnaryCall()` for consistency. All method types now return reactive types: `Mono` for UNARY and CLIENT_STREAMING, `Flux` for SERVER_STREAMING and BIDI_STREAMING. * Extract `createSingleSinkResponseObserver()` helper method to reduce code duplication between UNARY and CLIENT_STREAMING implementations. * Simplify `setMethodName()` to delegate to `setMethodNameExpression()` instead of duplicating flag-setting logic. * Replace `Iterator` usage with `List.get(0)` * Replace switch expression in `invokeStreamingCall()` with if-else r * Update tests to handle `Mono` return type from UNARY methods. Remove unused imports and simplify test helper methods. * Update reference documentation to reflect that all method types return reactive types instead of UNARY returning values directly.

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

artembilan · 2026-01-16T13:53:59Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+
+		Object request = requestMessage.getPayload();
+
+		this.logger.debug(() -> "Invoking gRPC method '" + methodDescriptor.getBareMethodName() +


Can we use the whole methodDescriptor here?
Perhaps that one includes a service name, too not just method.
I mean if we have several GrpcOutboundGateway against different gRPC services, it might be confusing just to see a method name in logs.

Was not addressed.

OK. We can live with that.
I just expected something like:

this.logger.debug(() -> "Invoking gRPC method '" + methodDescriptor + "' for request: " + request

But if you think that method name and service is enough, then OK.
Although, it looks like we could use then getFullMethodName() instead of that pair.

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

* Add `isAsync()` configuration option to control whether UNARY gRPC methods return `Mono` or direct response objects. When async mode is enabled, unary calls use `asyncUnaryCall()` and return `Mono<T>`. When disabled (default), unary calls use `blockingUnaryCall()` and return the response object directly. * Restore `invokeBlocking()` method for synchronous unary invocations to maintain backward compatibility with existing blocking behavior. * Add service name to debug logging for better traceability when invoking gRPC methods. * Simplify `invokeStreamingCall()` to use early return pattern instead of intermediate variable assignment. * Fix `createSingleSinkResponseObserver()` to call `tryEmitEmpty()` on completion for proper `Mono` handling. * Update Javadoc to document dual return type behavior for UNARY methods based on async configuration. Clarify method name resolution fallback logic in `setMethodName()` Javadoc. * Add test coverage for both async and blocking modes. Split single method test into separate async and blocking test cases. Add new test for async unary calls in multi-method test suite. * Update asciidoc to establish default mode of gateway is asynchronous * Update asciidoc to discuss Unary returns mono by default and result object if asnyc is set to false

artembilan

As a bonus I think we need an integration test involving flows for both server and client based on our both gateways.

artembilan · 2026-01-16T17:58:22Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+		this.grpcServiceClass = grpcServiceClass;
+		Method getServiceDescriptor = ClassUtils.getMethod(this.grpcServiceClass, "getServiceDescriptor");
+		this.serviceDescriptor = (ServiceDescriptor) Objects.requireNonNull(ReflectionUtils.invokeMethod(getServiceDescriptor, null));
+		this.setAsync(true);


No this. on method calls.
And we need to state in the class Javadocs that this gateway is an async by default.

artembilan · 2026-01-16T17:59:08Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+
+		Object request = requestMessage.getPayload();
+
+		this.logger.debug(() -> "Invoking gRPC method '" + methodDescriptor.getBareMethodName() +


Was not addressed.

artembilan · 2026-01-16T18:06:21Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+		return responseSink.asFlux();
+	}
+
+	@SuppressWarnings({"NullAway", "unchecked", "rawtypes"})


We probably need to revise this suppressions.

artembilan · 2026-01-16T18:06:56Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+
+		};
+
+		ClientCall call = this.channel.newCall(methodDescriptor, CallOptions.DEFAULT);


I wonder if we need to introduce a setter for custom CallOptions

artembilan · 2026-01-16T18:07:47Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+		return responseSink.asMono();
+	}
+
+	@SuppressWarnings({"NullAway", "unchecked"})


artembilan · 2026-01-16T18:22:31Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+}
+----
+
+3. **Dynamic resolution** from message headers using `setMethodNameExpression()`:


This does not reflect reality of the target expression.
However I agree that we need one more item to mention the default expression when many methods in the service.

artembilan · 2026-01-16T18:24:10Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+----
+
+If no `methodName` or  `methodNameExpression` is configured and there is only one method offered by the service then, that method's name will be used.
+If no `methodName` or  `methodNameExpression` is configured and the service has more than one method, the gateway uses the `GrpcHeaders.SERVICE_METHOD` header to determine which method to invoke.


I think both of these sentences are not required after all of those list items.
Especially, when we also move GrpcHeaders.SERVICE_METHOD default expression explanation over there into its own item.

artembilan · 2026-01-16T18:24:44Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+
+The `GrpcOutboundGateway` automatically detects the method type from the `MethodDescriptor` and handles the invocation appropriately:
+
+* **Unary** methods accept a single gRPC request message , returning a `Mono<ResponseType>` by default containing the response object.


I think comma needs to stick to the word it is used after.

artembilan · 2026-01-16T18:26:08Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+The `GrpcOutboundGateway` automatically detects the method type from the `MethodDescriptor` and handles the invocation appropriately:
+
+* **Unary** methods accept a single gRPC request message , returning a `Mono<ResponseType>` by default containing the response object.
+If `async` is set to `true` then the response object is returned.


This is something not true, since gateway produces a Mono in case of async.
I guess both these sentences need some rewording to explain behavior for async flag.

src/reference/antora/modules/ROOT/pages/grpc.adoc

cppwfs · 2026-01-16T19:52:21Z

Provide a sample of what you would like to see for this comment. The update contains method and service name.

Enhance the gRPC outbound gateway to support configurable call options: - Add `setCallOptions()` method with default `CallOptions.DEFAULT` - Apply call options to all RPC invocations (unary, streaming, bidi) - Improve debug logging to show full method descriptor - Remove unnecessary `NullAway` suppressions Refactor test organization and improve test naming: - Move inner classes to be nested within configuration classes - remove `setupGateway()` - Make validation methods static for better test structure - Rename test methods to remove "Proto" suffix Update documentation to clarify: - Default async mode is `true` for the gateway - Method resolution fallback using `GrpcHeaders.SERVICE_METHOD` header - Fix internal link to use xref notation - Document array support for client streaming requests

artembilan · 2026-01-16T21:21:10Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

 +
-If no `methodName` or  `methodNameExpression` is configured and there is only one method offered by the service then, that method's name will be used.
-If no `methodName` or  `methodNameExpression` is configured and the service has more than one method, the gateway uses the `GrpcHeaders.SERVICE_METHOD` header to determine which method to invoke.
+4. **Default method resolution** if method name or method name expression is configured and there are multiple methods offered by the service then, the gateway uses the `GrpcHeaders.SERVICE_METHOD` header to determine which method to invoke.


I think not is missed between is and configured.
I know I'm not good with English but that comma after then and before the looks suspicious.
I would expand the sentence a bit:

uses the `GrpcHeaders.SERVICE_METHOD` header resolution from the request message

Otherwise it is not clear what exactly that header belongs to.

artembilan · 2026-01-16T21:22:34Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

 ** `Mono<RequestType>`
 ** `Stream<RequestType>`
 ** `Collection<RequestType>`
+** `Array of RequestTypes`


If we go code snippet, then let's give a proper example to readers:

RequestType[]

!

artembilan · 2026-01-16T21:23:58Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

 	}

-	@SuppressWarnings({"NullAway", "unchecked", "rawtypes"})
+	@SuppressWarnings({"unchecked", "rawtypes"})


OK. I'll play with these rawtypes on merge.
Cannot judge properly from GH 😄
Sorry for the noise!

I'll submit another commit getting rid of the rawtypes.

artembilan · 2026-01-19T15:59:32Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	private Object invokeServerStreaming(Object request, MethodDescriptor<?, ?> methodDescriptor) {
+		Sinks.Many<Object> responseSink = Sinks.many().unicast().onBackpressureBuffer();
+
+		StreamObserver<Object> responseObserver = new StreamObserver<>() {


Looks like both invokeBidirectionalStreaming and this invokeServerStreaming do the same around responseObserver.
Can we extract that into an utility method like we have with the createSingleSinkResponseObserver?

artembilan · 2026-01-19T16:02:49Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+	}
+
+	private Object invokeBlockingUnary(MethodDescriptor<Object, Object> method, Object request) {
+		return ClientCalls.blockingUnaryCall(this.channel, method, this.callOptions, request);


Doesn't look like we need this single-line utility method.
Why don't call ClientCalls.blockingUnaryCall directly in the invokeUnary?

artembilan · 2026-01-19T16:06:05Z

...on-grpc/src/main/java/org/springframework/integration/grpc/outbound/GrpcOutboundGateway.java

+		Sinks.One<Object> responseSink = Sinks.one();
+
+		StreamObserver<Object> responseObserver = createSingleSinkResponseObserver(responseSink);
+		handleRequestAsFlux(request, responseObserver, method);


I think this is wrong here.
Perhaps copy/paste artifact.
The request has to go to UNARY as is, not as a streaming wrapper.
The responseObserver is handled by the gRPC client.
Not sure how tests works since you call streaming for unary...

In this case we are handling the async unary as a flux that converts to a mono.
i.e. a stream is a stream even if it only returns one Async item. We can discuss.

That is not correct. This is unary and there is a dedicated API you call in the end of this method. Why do we call streaming here?
You have already converted response observer to Mono and you propagate it down to asyncUnary call. Why do we do streaming if that was not requested?

I see the mistake. Thank you for bringing it to my attention.

artembilan · 2026-01-19T16:08:20Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+
+NOTE: GrpcOutboundGateway is asynchronous by default.
+However, to set the gateway to synchronous mode (specifically for the Unary gRPC communication pattern) use the `setAsync` method.
+More can read about asynchronous service activators xref:service-activator.adoc#async-service-activator[here].


This sentence is a bit awkward.
And I'm not a fun of here links.
Why just don't say like:

See more information in the xref:service-activator.adoc#async-service-activator[].

?

artembilan · 2026-01-19T16:10:14Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+}
+----
+
+3. **Dynamic resolution** establish expression to determine method name `setMethodNameExpression()`:


This sentence does not compile in my head.
How about:

**Dynamic resolution** via `setMethodNameExpression()`:

?

artembilan · 2026-01-19T18:11:36Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+}
+----
+
+4. **Default method resolution** if neither a method name nor a method name expression is configured, and the service offers multiple methods, the gateway uses the `GrpcHeaders.SERVICE_METHOD` header to determine which method to invoke.


Still missed from the request message context.
"Uses header" of what?
Imagine I'm new with Spring Integration, please, give me enough info to understand what is going on.

artembilan · 2026-01-19T18:15:37Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+The `GrpcOutboundGateway` automatically detects the method type from the `MethodDescriptor` and handles the invocation appropriately:
+
+* **Unary** methods accept a single gRPC request message, returning a `Mono<ResponseType>` by default containing the response object.
+The default `async` mode of the gateway is `true`.


I think this sentence is bit of context.
Feels like something else is missed in between.
How about just to say in the first sentence:

returning a `Mono<ResponseType>` containing the response object in async mode (by default).

Then this second sentence is redundant and the next one makes sense.

Extract duplicated `StreamObserver` creation into helper methods: - Add `createStreamSinkResponseObserver()` for streaming responses - Consolidate bidirectional and server streaming observer logic - Inline `invokeBlockingUnary()` into `invokeUnary()` caller - Remove unnecessary `handleRequestAsFlux()` call in async unary Polish documentation for clarity: - Simplify async service activator xref link - Clarify how message headers work in message name resolution - Remove redundant wording about async mode default

artembilan

OK. Pulling local for final review, clean up and merge.
Thanks

artembilan · 2026-01-20T14:10:25Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+}
+----
+
+4. **Default method resolution** if neither a method name nor a method name expression is configured, and the service offers multiple methods, the gateway will look for the `GrpcHeaders.SERVICE_METHOD` key in the headers of the message (if present) to determine which method to invoke.


if present what?
Message?
But it is always there because that is a request message for this message handler.

artembilan · 2026-01-20T14:11:01Z

src/reference/antora/modules/ROOT/pages/grpc.adoc

+
+The `GrpcOutboundGateway` automatically detects the method type from the `MethodDescriptor` and handles the invocation appropriately:
+
+* **Unary** methods accept a single gRPC request message, returning a `Mono<ResponseType>` by default containing the response object in async mode (by default).


Why do we have several "by default" in one sentence?

artembilan · 2026-01-20T15:33:33Z

Merged after some cleanup: 1f8caf7

Thank you!

cppwfs requested a review from artembilan January 8, 2026 16:40

artembilan requested changes Jan 8, 2026

View reviewed changes

cppwfs force-pushed the SI-grpc-outbound-gw branch 3 times, most recently from 4e4d0ae to 6d8595c Compare January 8, 2026 17:12

artembilan requested changes Jan 8, 2026

View reviewed changes

cppwfs force-pushed the SI-grpc-outbound-gw branch 2 times, most recently from a4de223 to 0611e36 Compare January 9, 2026 20:12

artembilan requested changes Jan 9, 2026

View reviewed changes

artembilan requested changes Jan 13, 2026

View reviewed changes

cppwfs added 4 commits January 15, 2026 14:16

cppwfs force-pushed the SI-grpc-outbound-gw branch from c315573 to 9a74cd8 Compare January 15, 2026 23:01

artembilan requested changes Jan 15, 2026

View reviewed changes

artembilan requested changes Jan 16, 2026

View reviewed changes

cppwfs added 2 commits January 16, 2026 16:32

Remove all rawtype suppressions

f7ca18b

Fix grammar explaining default expression

2ec4651

artembilan requested changes Jan 19, 2026

View reviewed changes

artembilan approved these changes Jan 20, 2026

View reviewed changes

Remove unnecessary syntax from grpc.adoc

27e2a14

artembilan closed this in d135beb Jan 20, 2026


		Object request = requestMessage.getPayload();

		this.logger.debug(() -> "Invoking gRPC method '" + methodDescriptor.getBareMethodName() +


		};

		ClientCall call = this.channel.newCall(methodDescriptor, CallOptions.DEFAULT);


		The `GrpcOutboundGateway` automatically detects the method type from the `MethodDescriptor` and handles the invocation appropriately:

		* Unary methods accept a single gRPC request message , returning a `Mono<ResponseType>` by default containing the response object.

Add gRPC outbound gateway for client calls #10684

Add gRPC outbound gateway for client calls #10684

Uh oh!

Conversation

cppwfs commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cppwfs commented Jan 8, 2026 •

edited

Loading