Repository navigation
Add support context propagation #225
Description
Activity
I'm doing some prototyping, will send a pr later.
@He-Pin thanks for providing the proposed implementation. I am thinking more about extending the McpServerExchange type to be per-request and encapsulate multiple concerns instead of adding more arguments. The exact shape will reveal itself once we have streamable http for stateless servers, which is coming.
This is really needed. Note: because of the use of the Mono/Reactor framework one cannot even use ThreadLocals as internal threads are used for everything. Separately, the use of that framework is a major limitation of this library and should be reconsidered IMO.
That's true, without this, we currently have to encode our context in the
arguments(path the JSON string, and then extract from the JSON string), which is a huge pain.@chemicL Thanks, we are actually starting using it, but I think we should add some type safe method for this, eg:
public <T> T get(@NonNull final TypedKey<T> key)Which is more like Netty's
AttributeKeyandAttributeMap, which is typesafe.Reacted by JiHwan OhI suppose some time has passed since
McpTransportContextwas introduced to address the concern from this issue and I'd like to close it.@He-Pin in case you feel the above type-safety proposal is still required, can you please open this as a new issue for the community to comment on? I suppose there might be more feedback on extracting the context by now.
Motivation:
When using the transport, we always need to pass some context from the context to the sessionFactory or handler, but with the current implementation, the original ServerRequest is completely been ignored, it would be nice that we pass this information down.
we have some kind of options:
I think the 3 is better, which will not bound to any implementation.