Updating ServerInterceptors.java to support different marshallers for Request and Response messages.

[ioanbsu]

Updating ServerInterceptors to support different marshallers for requests and responses.
See #9870 for more details.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ioanbsu / name: Ivan Bahdanau (56ba24f)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ioanbsu / name: Ivan Bahdanau (33bbb56)

[ejona86]

I expect in the future we'd want to have null marshaller mean "don't replace that marshaller." But that can be added in the future because this NPE's now in that case.

That style of test isn't my favorite, but it is mirroring the existing test for this, so is fair.

[ejona86]

Note for posterity: the encryption case here is a bit awkward because reflection and other tooling won't know about the shenanigans. There's ways to work around some of that, but they'd introduce some of their own interesting behavior. So I think the encryption case here is "a successful hack that may work well in limited situations." But it isn't something I'd expect to be supported in other languages or to encourage widely. So I'm not condoning this use-case, really, but would rather this than abusing Compressor.

I'm okay with this API though because it does make sense to be able to change the marshaller for request separately from response. Especially in the case where you only want to replace one (which falls into the null case I mentioned in my review, for future enhancement).

But I also think this API should be extremely rarely used. useMarshalledMessages() was added as a convenience during implementation of useInputStreamMessages(), so useMarshalledMessages() may have been unused by users up to this point, and I think useInputStreamMessages() makes a lot more sense to use for things like caching responses, logging, and the like.

[ioanbsu]

@YifeiZhuang, friendly ping.