Proposed enhancement to the ExpressionEvaluators

[Andrew Perepelytsya]

The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:

<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>

However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.

So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").

Andrew

[Ross Mason-4]

There is already support for doing this by calling ExpressionEvaluatorManager.parse(string, expression, ...), we just need to make sure that when those values are evaluated that the parse method is called, not the evaluate method.  There may be places where the "expression" method is being used since I introduced the parse method later on.

Cheers,

Ross Mason
CTO, Founder
MuleSource Inc.

http://mulesource.com | http://blog.rossmason.com

On Fri, Oct 24, 2008 at 6:38 PM, Andrew Perepelytsya <aperepel@...> wrote:

The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:

<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>

However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.

So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").

Andrew

[Andrew Perepelytsya]

Great! I knew I saw something like this already :)

You're right in that it was added later, currently only HTTP transport uses parse(), while everywhere else evaluate() is used. IMO, we should just replace all of them with parse(), and maybe even drop the evaluate() method (deprecate in 2.1.x, delete in 2.2). LMK if I missed anything, I'll file a JIRA then.

Now need only to pinpoint all those java.net.URI constructors and wrap them properly...

Andrew

On Mon, Oct 27, 2008 at 12:43 PM, Ross Mason <ross.mason@...> wrote:

There is already support for doing this by calling ExpressionEvaluatorManager.parse(string, expression, ...), we just need to make sure that when those values are evaluated that the parse method is called, not the evaluate method.  There may be places where the "expression" method is being used since I introduced the parse method later on.

Cheers,

Ross Mason
CTO, Founder
MuleSource Inc.

http://mulesource.com | http://blog.rossmason.com

On Fri, Oct 24, 2008 at 6:38 PM, Andrew Perepelytsya <aperepel@...> wrote:

The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:

<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>

However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.

So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").

Andrew

[Andrew Perepelytsya]

Here's the testcase which works fine: http://fisheye.codehaus.org/changelog/mule/branches/mule-2.x?cs=13152 It all comes down to plugging it nicely everywhere now.

Andrew

On Mon, Oct 27, 2008 at 1:51 PM, Andrew Perepelytsya <aperepel@...> wrote:

Great! I knew I saw something like this already :)

You're right in that it was added later, currently only HTTP transport uses parse(), while everywhere else evaluate() is used. IMO, we should just replace all of them with parse(), and maybe even drop the evaluate() method (deprecate in 2.1.x, delete in 2.2). LMK if I missed anything, I'll file a JIRA then.

Now need only to pinpoint all those java.net.URI constructors and wrap them properly...

Andrew

On Mon, Oct 27, 2008 at 12:43 PM, Ross Mason <ross.mason@...> wrote:

There is already support for doing this by calling ExpressionEvaluatorManager.parse(string, expression, ...), we just need to make sure that when those values are evaluated that the parse method is called, not the evaluate method.  There may be places where the "expression" method is being used since I introduced the parse method later on.

Cheers,

Ross Mason
CTO, Founder
MuleSource Inc.

http://mulesource.com | http://blog.rossmason.com

On Fri, Oct 24, 2008 at 6:38 PM, Andrew Perepelytsya <aperepel@...> wrote:

The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:

<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>

However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.

So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").

Andrew

[Ross Mason-4]

Excellent.  That sounds right.

Note that as this has been picked up in a current iteration, please file the issue then focus on tasks in the current iteration so that we burn down the existing work.  This issue can either be done at the end if there is time or scheduled for the next iteration.

Cheers,

Ross Mason
CTO, Founder
MuleSource Inc.

http://mulesource.com | http://blog.rossmason.com

On Mon, Oct 27, 2008 at 6:57 PM, Andrew Perepelytsya <aperepel@...> wrote:

Here's the testcase which works fine: http://fisheye.codehaus.org/changelog/mule/branches/mule-2.x?cs=13152 It all comes down to plugging it nicely everywhere now.

Andrew

On Mon, Oct 27, 2008 at 1:51 PM, Andrew Perepelytsya <aperepel@...> wrote:

Great! I knew I saw something like this already :)

You're right in that it was added later, currently only HTTP transport uses parse(), while everywhere else evaluate() is used. IMO, we should just replace all of them with parse(), and maybe even drop the evaluate() method (deprecate in 2.1.x, delete in 2.2). LMK if I missed anything, I'll file a JIRA then.

Now need only to pinpoint all those java.net.URI constructors and wrap them properly...

Andrew

On Mon, Oct 27, 2008 at 12:43 PM, Ross Mason <ross.mason@...> wrote:

There is already support for doing this by calling ExpressionEvaluatorManager.parse(string, expression, ...), we just need to make sure that when those values are evaluated that the parse method is called, not the evaluate method.  There may be places where the "expression" method is being used since I introduced the parse method later on.

Cheers,

Ross Mason
CTO, Founder
MuleSource Inc.

http://mulesource.com | http://blog.rossmason.com

On Fri, Oct 24, 2008 at 6:38 PM, Andrew Perepelytsya <aperepel@...> wrote:

The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:

<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>

However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.

So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").

Andrew

[Andrew Perepelytsya]

http://mule.mulesource.org/jira/browse/MULE-3893

Andrew