-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Sometimes we may have a context during message handling. See a DelegatingSessionFactory
as an example. So, we store some key
into the thread local, then SftpMessageHandler
obtain the session and and performs respective logic.
All this is done in the SftpMessageHandler
transparently, but in case of DelegatingSessionFactory
we just chose the target (S)FTP connection according previously mentioned key
stored in the thread local.
See more info in SO question and in docs.
So, current solution for the context holder is a bit involved, especially when we use one-way channel adapter for (S)FTP.
The proposed ContextHolderRequestHandlerAdvice
could be a single way to inject into such an outbound endpoint.
Its logic is pretty simple:
- Take a key from the request message
- Store the value into the context holder
- Invoke the
MessageHandler
- Clean the value from the context holder in the
finally
I feel like this advice can have these options:
keyProvider
- theFunction<Message<?>, Object>
to obtain the key from the message, or whatever source for the key is available. Could be as simple assetKeyProvider((m) -> m.getHeaders().get("myKey"));
contextSetHook
- aConsumer<Object>
- just delegates to the method on the target context holder. For example in case of the mentionedDelegatingSessionFactory
it could be like thissetContextSetHook(myDelegatingFactory::setThreadKey);
contextClearHook
- aConsumer<Object>
- just delegates to the method on the target context holder.For example in case of the mentionedDelegatingSessionFactory
it could be like thissetContextClearHook((key) -> myDelegatingFactory.clearThreadKey());
Probably internal logic could be implemented as a try-with-resource
.