Support of regex in header-value-router

[plecesne]

Hi,

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" />
</int:router>

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" />
</int:router>

Should I create a JIRA about that or do you see any drawback of this solution?

Thank you.

[oleg.zhurakousky]

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.

[Mark Fisher]

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.

[plecesne]

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.

[Mark Fisher]

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?

[plecesne]

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:

headers['myHeaders'].substring(0,3).concat(headers['myHeaders'].substring(headers['myHeaders'].size()-3)

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

com.sample.CriteriaBuilder.getCriteria(headers['myHeaders'])

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?

Pierre

[Mark Fisher]

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

[plecesne]

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"?