Details

    • Type: Sub-task Sub-task
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.3.M2
    • Component/s: None
    • Labels:

      Description

      Right now we're display the following :

      • <channel>
      • <publish-subscribe-channel>
      • <logging-channel-adapter> w/ channel connection
      • <inbound-channel-adapter> w/ channel connection
      • <outbound-channel-adapter> w/ channel connection
      • <recipient-list-router> w/ input channel connection
      • <bridge> w/ input & output channel connections
      • <chain> w/ input & output channel connections
      • <delayer> w/ input & output channel connections
      • <header-enricher> w/ input & output channel connections
      • <object-to-string-transformer> w/ input & output channel connections
      • <payload-deserializing-transformer> w/ input & output channel connections
      • <payload-serializing-transformer> w/ input & output channel connections
      • <service-activator> w/ input & output channel connections
      • <splitter> w/ input & output channel connections
      • <transfomer> w/ input & output channel connections
      • <aggregator> w/ input, output & discard channel connections
      • <filter> w/ input, output & discard channel connections
      • <resequencer> w/ input, output & discard channel connections
      • <header-value-router> w/ input channel & default output channel connections
      • <payload-type-router> w/ input channel & default output channel connections
      • <router> w/ input channel & default output channel connections
      • <gateway> w/ default request & default reply channel connections

      WONTDOs:

      • add reply & error channel conections to <header-enricher>

        Activity

        Hide
        Mark Fisher (c) added a comment -

        Here are answers to the first set of questions:

        • <logging-channel-adapter> w/ channel connection
          That is an "input" channel. That adapter is essentially an "outbound-channel-adapter" whose output is sent to the log.
        • <mapping> w/ channel connection
          That is just an inner element of a router. These are simply used to map values from the router ref/method's return value to a channel reference, and those mappings will be resolved dynamically. For example if the invoked method returns "foo", that value might be mapped to a channel named "fooChannel123".
        • <recipient> w/ channel connection
          That is similar to above, but in this case a statically configured recipient channel for the recipient-list-router. It probably does make sense in this case to display a connection. The recipient-list-router basically has an inverse relationship with a publish-subscribe-channel.
        • <wire-tap> w/ channel connection
          The wire-tap is a way to connect to one channel, intercept all messages there, and then send them to another channel. It would be good to show a connection, but keep in mind that it is the "secondary" path.
        • add reply & error channel conections to <header-enricher>
          It's probably best to avoid this one in the visualization (limiting to auto-completion assistance should be fine). For one thing, we'll be removing those attributes in 2.0 in favor of subelements. The actual referenced channel there is simply being stored within a header value for the Message that passes through that header-enricher. So, it would be confusing if we made it appear as though the output from header-enricher were being directed to those channels.

        Hope that helps.
        -Mark

        Show
        Mark Fisher (c) added a comment - Here are answers to the first set of questions: <logging-channel-adapter> w/ channel connection That is an "input" channel. That adapter is essentially an "outbound-channel-adapter" whose output is sent to the log. <mapping> w/ channel connection That is just an inner element of a router. These are simply used to map values from the router ref/method's return value to a channel reference, and those mappings will be resolved dynamically. For example if the invoked method returns "foo", that value might be mapped to a channel named "fooChannel123". <recipient> w/ channel connection That is similar to above, but in this case a statically configured recipient channel for the recipient-list-router. It probably does make sense in this case to display a connection. The recipient-list-router basically has an inverse relationship with a publish-subscribe-channel. <wire-tap> w/ channel connection The wire-tap is a way to connect to one channel, intercept all messages there, and then send them to another channel. It would be good to show a connection, but keep in mind that it is the "secondary" path. add reply & error channel conections to <header-enricher> It's probably best to avoid this one in the visualization (limiting to auto-completion assistance should be fine). For one thing, we'll be removing those attributes in 2.0 in favor of subelements. The actual referenced channel there is simply being stored within a header value for the Message that passes through that header-enricher. So, it would be confusing if we made it appear as though the output from header-enricher were being directed to those channels. Hope that helps. -Mark
        Hide
        Mark Fisher (c) added a comment -

        As for the second and third sets of questions, I would say that the discard-channels could be helpful. it might be nice to show a "secondary" connection (lighter shade/different color or something), and that same technique could be used for the wire-tap's channel.

        I would imagine that method connections might be displayed in a similar way to "actions" in the Web Flow visualizer/editor.

        Show
        Mark Fisher (c) added a comment - As for the second and third sets of questions, I would say that the discard-channels could be helpful. it might be nice to show a "secondary" connection (lighter shade/different color or something), and that same technique could be used for the wire-tap's channel. I would imagine that method connections might be displayed in a similar way to "actions" in the Web Flow visualizer/editor.
        Hide
        Leo Dos Santos (c) added a comment -

        From our face to face meeting:

        Remove <completion-strategy>, <mapping>, <method>, <recipient>, <selector> and <selector-chain> elements.
        Remove <interceptors> and <wire-tap> elements.
        Remove method connections

        Show
        Leo Dos Santos (c) added a comment - From our face to face meeting: Remove <completion-strategy>, <mapping>, <method>, <recipient>, <selector> and <selector-chain> elements. Remove <interceptors> and <wire-tap> elements. Remove method connections
        Hide
        Leo Dos Santos (c) added a comment -

        Also removing <thread-local-channel>

        Show
        Leo Dos Santos (c) added a comment - Also removing <thread-local-channel>
        Hide
        Leo Dos Santos (c) added a comment -

        Mark, I think we're on the same page now and our face-to-face meeting accomplished what I initially set out for this task. Closing.

        Show
        Leo Dos Santos (c) added a comment - Mark, I think we're on the same page now and our face-to-face meeting accomplished what I initially set out for this task. Closing.

          People

          • Assignee:
            Leo Dos Santos (c)
            Reporter:
            Leo Dos Santos (c)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: