Announcement Announcement Module
Collapse
No announcement yet.
Reference Manual feedback please! Page Title Module
Move Remove Collapse
This is a sticky topic.
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Well, we appreciate it. Every typo fixed is an improvement. You might find a few more Don't hesitate to let us know.

    Thanks!
    -Mark

    Comment


    • #47
      The 2.0.4 reference refers to a class I did not find in the release distribution zip file. Did this class move?

      class="org.springframework.integration.channel.Map BasedChannelResolver">

      Comment


      • #48
        Thanks for catching that. That has been refactored, and we should update the documentation. Can you please open a JIRA "task" for that?

        Thanks!
        -Mark

        Comment


        • #49
          Originally posted by Mark Fisher View Post
          Thanks for catching that. That has been refactored, and we should update the documentation. Can you please open a JIRA "task" for that?

          Thanks!
          -Mark
          Here is the Jira: https://jira.springsource.org/browse/INT-1938

          Comment


          • #50
            The online HTML manual makes reference to a MapBasedChannelResolver. This doesn't exist anymore as far as I can tell.
            cf http://forum.springsource.org/showth...esolver-in-RC1

            Thanks
            David

            Comment


            • #51
              That will be revised for 2.0.5. We have it as an issue in JIRA: https://jira.springsource.org/browse/INT-1938

              Thanks,
              Mark

              Comment


              • #52
                I created Jira https://jira.springsource.org/browse/INT-1950 for a reference manual incorrect link.

                Comment


                • #53
                  I hope there will be more infomation about monitoring and controlling the message flow,example : start, stop , resume, etc.

                  Comment


                  • #54
                    Specifically in the 1 to 2 Migration guide there's no reference to AbstractSingleChannelRouter being removed so that you need to extend a normal AbstractMessageRouter instead.

                    Because it didn't mention it nor work out of the box it was fairly mystifying.

                    Comment


                    • #55
                      So you were using AbstractSingleChannelRouter? that is interesting. I'll update the Migration Guide, but would you mind sharing your use case for using it in the first place?

                      Comment


                      • #56
                        Originally posted by oleg.zhurakousky View Post
                        So you were using AbstractSingleChannelRouter? that is interesting. I'll update the Migration Guide, but would you mind sharing your use case for using it in the first place?
                        Oleg, it was used in a codebase I inherited a few months ago. Looking at it the use case was as effectively a binary router:

                        Having checked some 'state' in the Message it either:
                        - returns null, and is sent to the "default-output-channel"
                        - or is routed to the channel specified in the xml (passed in to the constructor)

                        It only took a little work to convert to AbstractMessageRouter once I knew that's what I needed to do.

                        More time was spent working out what happened to AbstractSingleChannelRouter and that AbstractMessageRouter was the thing to use in Spring 2 as I could find no reference to it (or the decision)

                        Comment


                        • #57
                          It doesn't sound like that use-case should require a custom implementation. It could most likely be handled as a simple POJO invocation from a normal 'router' element (or in 2.0, using a SpEL expression instead of the POJO). Also, it might be worth considering a 'filter' element, where the expression or POJO-method-return-value can be a simple boolean. When TRUE the Message goes to the output-channel, and when FALSE it goes to a discard-channel if one has been provided (in such a case, it too can serve as a "binary router").

                          Hope that helps.
                          -Mark

                          Comment


                          • #58
                            Mark,

                            Thanks very much for the suggestions.

                            I'm happy that it's existence probably wasn't justified, it was just I couldn't migrate by 'just turning the handle' (which might actually be a good thing I suppose!)

                            But its the old 'legacy code' problem where the original decision is lost to the mists of time and upgrading SI was part of getting the codebase under control.

                            A reference to AbstractSingleChannelRouter in the migration guide would (have) suffice(d), perhaps with why it was removed (too niche an application?).

                            Perhaps any further discussion should take place in a new thread.

                            Regards
                            David

                            Comment


                            • #59
                              I understand and agree that it should be mentioned in the migration guide. I just wanted to make sure you knew why it's typically not necessary to extend those framework classes in the first place. Thanks again though for bringing up the topic - we will definitely add it to the doc.

                              Comment


                              • #60
                                Originally posted by MmarcoM View Post
                                any tips as well on how to use ApplicationEvent?

                                if springapp services could be managed via JMX?

                                regards
                                marco
                                A pdf version would be good.

                                An overview of how spring integration compares with other intergration frameworks (or esbs) such as mule or servicemix would be useful.

                                Detailed documentation on the tags would be useful. If there are annotation versions of the tags, it would be best if the xml tags were documented by reference to the annotation classes as well as comments in an xsd.
                                _____________________
                                website promotion

                                Comment

                                Working...
                                X