Announcement Announcement Module
Collapse
No announcement yet.
Retrieve message based on the payload Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Retrieve message based on the payload

    The API allows me to deal either with Spring's message or the payload itself:

    public class SomeEndpoint {
    Message<SomePayloadClass> doSomething(AnotherPayloadClass payload)
    {
    ...
    }
    }

    What if I deal only with the payload and later I realize I need the message (e.g. the get some header information)?

    I am concerned that when using SI over time there will be lots of classes and I do not want to refactor them only the deal with messages instead of payloads.

    Is there a convenient way of getting the message for a certain payload?

    Thanks Tai

  • #2
    If you need to access the Message, you can change the signature to accept the Message itself (return type does not necessarily need to change):
    Code:
    Message<SomePayloadClass> doSomething(Message message) {...}
    Alternatively, if you need to access specific header values, you can add additional parameters with the @Header annotation:
    Code:
    Message<SomePayloadClass> doSomething(AnotherPayloadClass payload, @Header("x") String x, @Header("y") int y) {...}

    Comment


    • #3
      The @Header annotation is very useful. But imagine the following Type Hierarchy:

      Class A
      Class B and C extends from A; where B overrides:
      PayloadClass doSomething(AnotherPayloadClass inputPayload)

      In case for class C I realize that I need some header information. It would be ugly to refactor all classes to use the header annotation as a parameter.

      I do also not know what happens at runtime with overloaded methods like in the C class:

      //new method including header annotation along with the unchange method from B
      PayloadClass doSomething(AnotherPayloadClass inputPayload, @Header("x") String headerX)

      Both approaches aren't that nice (especially when dealing with legacy code). Maybe the best practice is to always deal with Spring's Message class for a parameter instead of the payload? Which isn't the best solution either (dependency to Spring, payload must be explicitely retrieved) .

      Comment


      • #4
        an &quot;Aware&quot; interface

        Maybe there should something like MesseageHeadersAware (with a set/getHeaders() - similar to the ApplicationContextAware).

        Meaning: I just need to implement the interface and when the message handler calls the bean it attaches the header.

        Would that be a proper solution?

        Comment

        Working...
        X