Announcement Announcement Module
No announcement yet.
Channel Interceptors Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Channel Interceptors

    Is there a clean way to apply interception? I don't think the writing of interceptor beans is the cleanest way to do this for simple cases. In my use case I have 15 endpoint channels. An XML splitter sends the results to an XML router that then routes to one of the 15 depending on part of the XML message. The problem is that I need to apply an XSL transformation to each of the 15 endpoint channels before they receive it. As far as I can tell, the only way to do this is to put the XSL transformation in front of each of the 15 endpoints and have the router route to them instead of the endpoints at which time the XSL transform will execute and route to the endpoint. This seems like an unnecessary PITA.

    Is there a way to just intercept each endpoint's inbound channel and perform the XSL without resorting to writing a bean just for this purpose? It seems like overkill, and double work, to do this when the XSL transformer is perfectly suited for my functional needs. It only needs to be more flexible in its application.

  • #2
    You can route to 15 chains, and include in each chain XSLT and the original endpoint. This way the configuration will stay compact with minimum redundancy


    • #3
      Maybe I just don't understand, but this is throwing an exception:

      	<!-- route the order to all responders-->
      	<si:channel id="serviceMessagesChannel" />
      	<si-xml:xpath-router id="serviceMessageRouter"
      		input-channel="serviceMessagesChannel" xpath-expression-ref="channelSelector"
      		multi-channel="false" />
      	<si:chain input-channel="myServiceChannel">
      		<si-xml:xslt-transformer id="soapMessageTransformer"
      			xsl-resource="classpath:xsl/soap.xsl" />
      		<si-stream:stdout-channel-adapter id="myServiceChannelStdOut"
      			append-newline="true" />
      The router's xpath determines where to send the message. This works without the chain (and the ids and channels in place). I plan on swapping out the stdout adapter for my WS service outbound-endpoint once I get this working, but it doesn't seem to like the channel adapter. Will it work with a ws:outbound-gateway? I can't test that until I'm in my integration environment, which is a long way to go just to see if it works.

      The code above throws this:
      Caused by: java.lang.IllegalArgumentException: Cannot convert value of type [org.springframework.integration.endpoint.EventDrivenConsumer] to required type [org.springframework.integration.message.MessageHandler] for property 'handlers[1]': no matching editors or conversion strategy found


      • #4
        Please create an issue for that with your testcase attached. I don't see a good reason why you should get that exception, and I see a lot of good reasons that it should just work.


        • #5
          The reason the exception is thrown is that the channel-adapter is parsed directly into an EventDrivenConsumer rather than a MessageHandler. The elements in the chain are all required to be MessageHandlers so that the actual consumer can be created with the anonymous channels, etc.

          That said, I agree with Iwein in so far as that is not a *good* reason, it just happens to be the reason due to our current implementation. This will require some non-trivial updates to the parsing logic for channel adapters, but if you create an issue for it, we can add it to the 1.0.3 roadmap. In the meantime, you can add each filter+channel-adapter explicitly. Perhaps grouping them together will make it easier to refactor into chains once this is resolved.