Announcement Announcement Module
No announcement yet.
Message handler chain with several service-activators Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Message handler chain with several service-activators

    In the chapter 13.2 of the documentation, it is written that a the chain can support several <service-activator>s. My code is pretty trivial:

        <si:chain input-channel="events">
            <si:service-activator ref="processor" method="method1"/>
            <si:service-activator ref="processor" method="method2"/>
        <bean id="processor" class="mypkg.EventProcessor"/>
    When the code is executed, only the method1 is invoked.

    The EventProcessor is implementing the method
    public void setOutputChannel(MessageChannel outputChannel)
    but it is never called.

    I am missing something stupid but I don't see what. It's maybe too late also...


  • #2
    The setOutputChannel(MessageChannel) method here would not be called, since it is the adapter invoking this code that is aware of output channels. When invoking a pojo via ref+method attributes like this, your code does not need to know anything about the MessageChannel.

    Can you provide the method signature for method1? Specifically, is it a void-return?


    • #3
      Originally posted by Mark Fisher View Post
      Can you provide the method signature for method1? Specifically, is it a void-return?
      the method are both returning void.

      Following your hint, I changed the first method to return the message (a String) and everything worked fine (both methods are executed without error).

      Note that if both methods return the message, an exception occurs ("no replyChannel header available").

      What I was looking for a a way to chain the processing of the same message by different handlers without having to do any unnecessary routing. I like the solution of chaining the <service-activator>s but find a little bit strange (although understandable) that the methods have to be "processing aware" (i.e. they must return the message if they are not the last one to be invoked in the chain; this makes adding new activators difficult without changing the code).

      Is there a way to be able to freely order the service-activators, maybe by implementing a marker interface?

      Thanks for having taken the time to answer my question.


      • #4
        This made perfect sense to me before, but it seems that from a user perspective the rules are perhaps not as obvious as we thought.

        Maybe passing the same message to the next handler if the return type is void makes more sense to you?

        The thing you say about services having to be aware of the chain order is only true when you don't set a reply channel on the message and on the chain, so it's not that bad imo.