After commit d63e854, the local testing shows this O/P. Getting "getFKingdomValue" in the method name.

Code changes description:
createRequestFieldGetterExpr() is being called in both cases (routing_header rule present v/s absent) to map the parameters.

In first case (routingHeaderRule() == null, createRequestParamsExtractorBodyForHttpBindings() is called), createRequestFieldGetterExpr() is modified to accept an extra boolean parameter, isFieldEnum(). And if the field is enum, I am adding an extra “Value” to the fieldMethod name (https://github.com/googleapis/sdk-platform-java/pull/2328/files#diff-13cc1d69966fca5c433b2c243aa4e8414520cf05e295f02ed52f2fe5097cac21R1474) during the last iteration of the descendant fields.

In the 2nd case when routingHeaderRule()!=null, I am sending false in isFieldEnum() because routingHeaderParam does not have anything to check if it is an enum or not (or is there? I am not able to find it).

Since this only solves the implicit routing headers, can you please create a separate issue to track it and update the description of this PR accordingly? Leaving a comment at #1966 would be great as well.

Done. Here is the issue created - #2368

FYI @ddixit14, we have Showcase ITs for Dynamic Routing Headers at https://github.com/googleapis/sdk-platform-java/blob/762c125abadb5e56682224c9f1587c71e5c6e653/showcase/gapic-showcase/src/test/java/com/google/showcase/v1beta1/it/ITDynamicRoutingHeaders.java

I think the compliance.proto has a enum field that you can possibly test against. It may be possible to add a test to intercept the the enum value is sent as an int value in the headers.

Also, we talked earlier about possibly enhancing echo.proto to also test for some explicit + implicit dynamic routing enum use cases. I took another look into echo.proto and I think it makes sense since a bulk of the routing header test cases are there: https://github.com/googleapis/gapic-showcase/blob/330a3a25eb8c4d0948860f1898fe7dcc05dc4ea5/schema/google/showcase/v1beta1/echo.proto#L48-L86

I think you can create an issue in the gapic-showcase repo and someone can pick it up in the future.

Also, we talked earlier about possibly enhancing echo.proto to also test for some explicit + implicit dynamic routing enum use cases. I took another look into echo.proto and I think it makes sense since a bulk of the routing header test cases are there: https://github.com/googleapis/gapic-showcase/blob/330a3a25eb8c4d0948860f1898fe7dcc05dc4ea5/schema/google/showcase/v1beta1/echo.proto#L48-L86

I think you can create an issue in the gapic-showcase repo and someone can pick it up in the future.

If we already have a test case in compliance.proto, what is the advantage of adding one to echo.proto? Is it mostly for simplifying our showcase tests, so that we don't have to create a separate ComplianceClient? If it's for latter, I don't think we have to add one.
Ideally the showcase protos should be grouped into features, so that routing header test cases can be in a dedicated proto. Before that happens, I think having implicit routing header test case in a separate proto is OK.

Also, we talked earlier about possibly enhancing echo.proto to also test for some explicit + implicit dynamic routing enum use cases. I took another look into echo.proto and I think it makes sense since a bulk of the routing header test cases are there: https://github.com/googleapis/gapic-showcase/blob/330a3a25eb8c4d0948860f1898fe7dcc05dc4ea5/schema/google/showcase/v1beta1/echo.proto#L48-L86
I think you can create an issue in the gapic-showcase repo and someone can pick it up in the future.

If we already have a test case in compliance.proto, what is the advantage of adding one to echo.proto? Is it mostly for simplifying our showcase tests, so that we don't have to create a separate ComplianceClient? If it's for latter, I don't think we have to add one. Ideally the showcase protos should be grouped into features, so that routing header test cases can be in a dedicated proto. Before that happens, I think having implicit routing header test case in a separate proto is OK.

For now, it's mainly for the latter reason. Agreed that ideally we would have a separate showcase proto for routing headers, but it looks like the explicit headers are mostly contained in the echo proto. It's not urgent to add an enum to the echo proto, but a smaller task to enable showcase tests for more routing headers use cases is to add it there (especially for any future explicit enhancements/ improvements). In the future/whenever someone has the time, we can create a new proto specifically for routing headers.

Quality Gate passed for 'gapic-generator-java-root'

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
94.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

Quality Gate passed for 'java_showcase_integration_tests'

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud