[#MULE-3893] Improve Expression Evaluation framework to support multiple nested expressions in literal strings

Mule

Improve Expression Evaluation framework to support multiple nested expressions in literal strings

Created: 28/Oct/08 10:08 AM Updated: 20/Nov/08 11:15 AM

Component/s:

Core: API, Core: Configuration

Affects Version/s:

2.1.1

Fix Version/s:

2.x Product Backlog

Time Tracking:

Not Specified

Issue Links:

Block

This issue blocks:

MULE-2312 Supporting dynamic properties in Mule, especially on endpoints.

Related

This issue relates to:

~~MULE-3970~~ Add a String Expression evaluator

Labels:
User impact:	High
Effort points:	2
Affects Docs:	Yes
Migration Impact:	« Hide Reference docs will need to mention that literal strings can now be evaluated (expressions nested inside any string, compare this to having expression exclusively as a value now). Writing custom evaluators page will need to be updated to mention the deprecated API and provide guidance on the recommended usage. Show » Reference docs will need to mention that literal strings can now be evaluated (expressions nested inside any string, compare this to having expression exclusively as a value now). Writing custom evaluators page will need to be updated to mention the deprecated API and provide guidance on the recommended usage.

Description

« Hide

http://www.nabble.com/Proposed-enhancement-to-the-ExpressionEvaluators-td20154569.html

This is an enabling improvement bringing us one step closer to the truly dynamic enpoints.

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Ross Mason added a comment - 31/Oct/08 10:07 AM

Note that this is a non-issue since the ExpressionManager already supports processing multiple expressions in a string using the parse method

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 03/Nov/08 03:34 PM

Had a couple discussions on the subject:

evaluate() will stay and be used for cases when non-String result is returned (e.g. attachment, node in xpath)
parse() will replace evaluate() wherever possible (e.g. String return value).

[ Permlink | « Hide ]

Ross Mason added a comment - 20/Nov/08 10:55 AM

Is this fixed by ~~MULE-3970~~?

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 20/Nov/08 11:15 AM

Probably yes, though the recent change uses the #[string:xxx] form. It may not work OOTB for e.g. path configuration unless it is supported explicitly (probably another task).