Make JmsMessageRequester support expressions in selector

Hi David. The only problem with doing it is that expression manager will not have a message instance, and there's no way it could, as selector is set on the consumer at creation time, before it has a chance to consume anything and return a message.

This, however, may simply mean that you'll not be able to use evaluators relying on a message, but any other evaluator would still work. Is it in line with your expectations?

Absolutely in line.

As you said it, there is still a couple of expression evaluators that could provide some goodness (for ex, in my case, function:systime).

Could you please post a sample config on how you'd be using it? That would help in creating the test case.

Sure! Here you go:

<quartz:inbound-endpoint cronExpression="0/5 * * * * ?"
jobName="queuePoller">
<quartz:endpoint-polling-job>
<quartz:job-endpoint
address="jms://queue?selector=JMSTimestamp+${messageDelay}%3C%3D%23[function:systime]"
timeout="1000" />
</quartz:endpoint-polling-job>
</quartz:inbound-endpoint>

Ok, I see now. I'd recommend you instead use a jms-specific endpoint with a nested selector config element and then reference it in quartz job-endpoint. This way the URI escaping may be avoided.

In fact, this is what I did:

<jms:endpoint name="delayedQueue" queue="queue">
<jms:selector expression="JMSTimestamp+${messageDelay}<=#[function:systime]"/>
</jms:endpoint>

I just put everything together to post a shorter config snippet (for which it took me some time to figure out the HEX escaping LOL).

I may have a better design for this behavior... I have done the following:

• subclass JmsSelectorFilter:

@Override
public String getExpression() { return ExpressionEvaluatorManager.parse(super.getExpression(), null); }

• declare this custom filter in the global JMS endpoint:

<jms:endpoint name="delayedQueue" queue="queue">
<custom-filter class="my.JmsExpressionSelectorFilter">
<spring:property name="expression" value="JMSTimestamp+${messageDelay}<=#[function:systime]" />
</custom-filter>
</jms:endpoint>

• use a standard quartz:endpoint-polling-job

This is clean enough for me, I can live with this approach without any code change from your side. Consequently, you can close/wont fix this JIRA if you don't see any extra value in altering the existing dispatcher (which I think is good to leave as it is).

David,

There are some issues with the approach above:

1. 2.2 has refactored the expression evaluator framework to drop statics
2. if a filter always returns the processed value, there's no other way to get the original template

Anyway, I've committed a tentative change to support your scenario: http://fisheye.codehaus.org/changelog/mule/?cs=13848
The 2.2 snapshot deployment build is pending, you can grab it once it finishes (or just build from source): http://bamboo.mulesource.org/browse/MULE-MULE2XSNAPSHOTS/log

I'd appreciate if you tested this on your side and let us know if it fits the use case.

One more: http://fisheye.codehaus.org/changelog/mule/?cs=13850

Andrew, thanks for warning me about the compromised future of my "solution".

I have tested the endpoint+selector approach with Mule 2.1.0-SNAP and it works perfectly well! Thanks!

D.

Wondering how would I ever reliably test something like this (timing...). Closing as fixed