Consider adding AbstractStub.withCallOptions()

[ejona86]

It would fully overwrite the current CallOptions. That could be considered "bad" because you don't know what you are overwriting, but it seems there are fine times to do so. Maybe it would be better to have a new generated method newStub(channel, callOptions) instead?

[IvanVas]

Totally agree. I was surprised not to see the newStub function that would accept CallOptions

[marcomorain]

I came looking for this functionality, too. I want to be able pass a CallOptions to the generated newBlockingStub functions.

[SreeramdasLavanya]

@shivaspeaks

As per this defect my understanding is newStub(channel, callOptions) to be introduced but in the codebase I can see this method is part of AbstractStub, so can you please provide what else to be needed.

[shivaspeaks]

Looks like newStub(channel, callOptions) is added as part of #6458

[ejona86]

You're talking about on StubFactory? That's an API for AbstractStub to call; there's no way for a user to call it.

The newStub() mentioned is talking about the generated code. There's one of those methods per stub type.

[SreeramdasLavanya]

@ejona86 , @shivaspeaks

As per analysis we have made the https://github.com/grpc/grpc-java/pull/11734/files#:~:text=public%20final%20S%20withChannelAndCallOption,%7D changes in grpc-stub project with newly overloaded method, we stuck with validating the changes and need your directions to move forward.