Spring Integration
  1. Spring Integration
  2. INT-191

Allow "multi-action" methods in a single Message Endpoint

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0 Final
    • Component/s: Core
    • Labels:
      None

      Description

      Allow multiple methods in a single Message Endpoint (e.g. multiple methods with @ServiceActivator). The Barista is a good example (two handler methods for different channels), but he can't be implemented using annotations. It should be like a @Controller and @RequestMapping - the @RequestMapping can narrow the request to a special channel, or take the default for the class.

        Issue Links

          Activity

          Hide
          Mark Fisher added a comment - - edited

          This also raises the question: do we want to support hierarchical channels, so that a MessageEndpoint's channel-mapping could use wildcards (e.g. "drinks/**") while the @ServiceActivator could match the remainder of the "path" (e.g. @ChannelMapping("hot")).

          I like the consistency here with Spring's @MVC style, and I have been considering the potential value of having such a hierarchy for channels.

          One other somewhat related note, I opened another issue for adding parameter-binding annotations for Message header values, etc (these binding annotations would also be useful for transformation, etc): INT-192

          Show
          Mark Fisher added a comment - - edited This also raises the question: do we want to support hierarchical channels, so that a MessageEndpoint's channel-mapping could use wildcards (e.g. "drinks/**") while the @ServiceActivator could match the remainder of the "path" (e.g. @ChannelMapping("hot")). I like the consistency here with Spring's @MVC style, and I have been considering the potential value of having such a hierarchy for channels. One other somewhat related note, I opened another issue for adding parameter-binding annotations for Message header values, etc (these binding annotations would also be useful for transformation, etc): INT-192
          Hide
          Mark Fisher added a comment -

          We now have different annotations for each type of endpoint (e.g. @Transformer, @Splitter, and @Router), and while not the recommended configuration approach, we do also now allow channels to be specified on these method-level annotations.

          I'm keeping this open for RC2, however, since we may also consider enabling configuration of the MethodResolver strategy (currently, the DefaultMethodResolver is capable of looking for an annotation or a single public method). This may also involve some refactoring of the MessageMappingMethodInvoker. For example, the MethodNameResolvingInvoker could be supplemented by a dynamic payload-type-matching resolver.

          Show
          Mark Fisher added a comment - We now have different annotations for each type of endpoint (e.g. @Transformer, @Splitter, and @Router), and while not the recommended configuration approach, we do also now allow channels to be specified on these method-level annotations. I'm keeping this open for RC2, however, since we may also consider enabling configuration of the MethodResolver strategy (currently, the DefaultMethodResolver is capable of looking for an annotation or a single public method). This may also involve some refactoring of the MessageMappingMethodInvoker. For example, the MethodNameResolvingInvoker could be supplemented by a dynamic payload-type-matching resolver.
          Hide
          Mark Fisher added a comment -

          MessageMappingMethodInvoker now delegates to a HandlerMethodResolver, and when multiple Methods are available for an adapter (either matching an annotation or 'methodName'), the PayloadTypeMatchingHandlerMethodResolver will be used. It determines the closest match based on the Message payload type at runtime.

          See the commit log for details:
          https://fisheye.springframework.org/changelog/spring-integration/?cs=1712

          Show
          Mark Fisher added a comment - MessageMappingMethodInvoker now delegates to a HandlerMethodResolver, and when multiple Methods are available for an adapter (either matching an annotation or 'methodName'), the PayloadTypeMatchingHandlerMethodResolver will be used. It determines the closest match based on the Message payload type at runtime. See the commit log for details: https://fisheye.springframework.org/changelog/spring-integration/?cs=1712

            People

            • Assignee:
              Mark Fisher
              Reporter:
              Dave Syer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: