Announcement Announcement Module
No announcement yet.
Support of regex in header-value-router Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support of regex in header-value-router


    Do you think it might be possible to add regex support on the <header-value-router> tag ?

    Like instead of :

    <int:header-value-router header-name="myHeader" input-channel="inputChannel"	>
    	<int:mapping value="TPA123" channel="tpa" />
    	<int:mapping value="TPA124" channel="tpa" />
    	<int:mapping value="TPA255" channel="tpa" />
    	<int:mapping value="CFU100" channel="cfu" />
    	<int:mapping value="CFU210" channel="cfu" />
    The following would be nice (just an example):

    <int:header-value-router header-name="myHeader" input-channel="inputChannel"	>
    	<int:mapping value="TPA.*" channel="tpa" />
    	<int:mapping value="CFU\d+" channel="cfu" />
    Should I create a JIRA about that or do you see any drawback of this solution?

    Thank you.

  • #2
    Yes create a JIRA

    Also, we have similar support in other components and its is based not on Regex but on simple pattern matching (e.g., TPA*, *2* etc.), which would satisfy your requirement anyway and would be consistent with everything else we do.
    Can't promise if it'll make its way to 2.0.GA, but certainly 2.0.1.


    • #3
      Before posting a feature request, let's see if we can find a way to handle the use-case with existing functionality. Generally, I want to avoid adding multiple options for the same behavior. If it turns out that nothing currently supports it well, then perhaps a regex and/or pattern option for the header-value-router is worth adding.

      First, I would just consider what can be done with 'expression' on a simple <router>. SpEL supports Regular Expressions via the 'matches' keyword. Maybe that combined with regular <mapping> sub-elements would be sufficient? Also, the <recipient-list-router> supports 'selector-expression' attributes.


      • #4
        I may have misunderstood your point Mark, but in my case, I need the regex to be on the value of the <mapping> element, not on the expression selection.
        And I suppose that the <mapping> subelements of <router> and <recipient-list-router> don't allow pattern matching either.


        • #5
          If the example you posted is covering your use case, you could probably just use a simple <router> with an "expression" attribute. The expression could get the "myHeaders" header and call substring(3) on it.

          Or... is your real use-case more complex?


          • #6
            Oh ok, now I understand, sorry!

            Well, my use-cases are not much, but a little bit more complicated (three first and three last characters of the words: "TPA*XXX", "TPA*YYY", "CFU*XXX", ...). As barely anything can be executed in SPeL, I guess that I'll always found a way to handle it that way.

            However, the expression would be quite long I think... Something like the following maybe:

            Another option would be to implement the rules in another class CriteriaBuilder and have the following SPeL:

            Still, I believe that just adding a star to the mapping would probably be more intuitive and easier to read (and so to maintain), wouldn't it?

            I know that you don't like to have two ways of doing the same thing, but using expressions in my case really looks like a workaround. I don't think it's bad to have two ways of doing the same thing as long as there is always a more appropriate and elegant one for a given situation.

            What do you think?



            • #7
              You might want to look at <recipient-list-router>. It actually allows for "selector-expression" on a per-recipient basis.


              • #8
                Thank you, Mark.

                I've just had a look on JIRA #578 to understand how to use the "selector-expression" attribute in <recipient-list-router>: I'll still need the complicated SPeL expression I quoted above, right?
                Or did you think about something else, or did I not understand properly the use of the "selector-expression"?