Context Propagator giving errors, limitation while using MDC in custom propagators

We have a spring boot application, in which temporal workers are also running.
we want to propagate ServletRequestAttributes from service class to workflow.

  1. Tried writing CustomPropogator. in getCurrentContext() method got all the reqAttributes which were present in the service class. Now getting a few errors as mentioned below.
  public Object getCurrentContext() {
    Map<String, Object> contextMap = new HashMap<>();
    var requestAttrs = RequestContextHolder.getRequestAttributes();
    System.out.println("in getCurrentContext requestAttrs " + requestAttrs);
    if (Objects.nonNull(requestAttrs)) {
      HttpServletRequest request = ((ServletRequestAttributes) requestAttrs).getRequest();
      Enumeration<String> s = request.getAttributeNames();
              i -> {
                //System.out.println("key inside getCurrentContext:" + i);
                contextMap.put(i, request.getAttribute(i));

    return contextMap;

a) Now in setCurrentContext() method tries to set the context in MDC. so that MDC can be used in wofkflowImpl and ActivityImpl class to pass the context info further.
The Problem is MDC takes only string as its key and value but reqAttributes are not necessary to be in string form. so how to propagate such objects.
b) If we are using MDC, which is the right place to clear all entries from MDC once execution is complete.

  public void setCurrentContext(Object context) {
    Map<String, Object> contextMap = (Map<String, Object>) context;
    for (Map.Entry<String, Object> entry : contextMap.entrySet()) {
      try {
          MDC.put(entry.getKey(), (String) entry.getValue());
c)Are there any alternative solutions available instead of MDC, so we can use context in workflow and activity. 
 d) Many objects throw errors during serializing/deserializing method of the custom propagator, here is the code of that methods.
  public Map<String, Payload> serializeContext(Object context) {
    Map<String, Object> contextMap = (Map<String, Object>) context;
    Map<String, Payload> serializedContext = new HashMap<>();

    for (Map.Entry<String, Object> entry : contextMap.entrySet()) {
    return serializedContext;
  public Object deserializeContext(Map<String, Payload> context) {

    Map<String, Object> contextMap = new HashMap<>();
    for (Map.Entry<String, Payload> entry : context.entrySet()) {
          contextMap.put(entry.getKey(), DataConverter.getDefaultInstance()
                  .fromPayload(entry.getValue(), Object.class, Object.class));
    return contextMap;
  1. Tried implementing the Interceptor concept as well, but they also have access to WorkflowInput/ActivityInput. What is the recommended way to pass certain context-related information via Interceptors?
  2. WorkflowInput/ActivityInput has header information in it. Can we leverage this header to somehow pass our information? Need to understand how is the header populated here.

It would be great if we can get some samples around this.
Thanks in advance !!!.

Hi @Prateek_Pagaria, what are you using the ServletRequestAttributes for in your workflow and activities? Note that you can annotate Activity impls with “@Component” and could inject/autowire it there if needed, just make sure that you register an injected activity impl with the worker.

Hi @tihomir
From ActivityImpl we are trying to make a rest call to one of our internal micro-service, that rest call goes via DAPR ( so we are leveraging one of the building blocks of DAPR to make a rest call via HTTP. DAPR also gave tracing functionality, that trace-id is in that ServletRequestAttributes , so we want that trace id to propagate til activity level.
Is activity injection right to use? Cannot we use Context Propagator / Interceptor to achieve this?
I did not get how activity injection will help in this case?

@tihomir in one of the forum page you have mentioned not to annotate workflow/activity with any spring boot annotation. .

Can you clear once again . should we annotate our activities with “@component” .? If not then why.?
And how does annotating will help in case of context propagator

Nice catch! I was incorrect in that statement and little later created GitHub - tsurdilo/activities-component to test that indeed you can do it for activities. Will update.
Here is activity registration: activities-component/ at main · tsurdilo/activities-component · GitHub
It would allow you to use di in your activities.