Thank you Adrian, much appreciated.
I have a question about one of the changes you have committed:

+            if (this.resultFma.containsNestedExpression()) {
+                String expression = (String) 
this.resultFma.get(methodContext.getEnvMap());
+                FlexibleMapAccessor<Object> resultFma = 
FlexibleMapAccessor.getInstance(expression);
+                resultFma.put(methodContext.getResults(), fieldVal);
+            }...

if I read it correctly, if a nested expression is detected then a new FMA is 
created as a local variable and the result value is added to that instead of 
adding it to the instance FMA. Aren't we loosing the result in this way?

Thanks,

Jacopo

On May 14, 2012, at 10:50 PM, Adrian Crum wrote:

> Jacopo,
> 
> I committed a fix in rev 1338394. Let me know if that solves your problem.
> 
> -Adrian
> 
> On 5/14/2012 1:54 PM, Adrian Crum wrote:
>> Then that seems to be a flaw in the <field-to-result> logic. I will look 
>> into it.
>> 
>> -Adrian
>> 
>> On 5/14/2012 1:51 PM, Jacopo Cappellato wrote:
>>> Ok, I am debugging it and the problem is actually in the method 
>>> FlexibleMapAccessor.put at line:
>>> 
>>> UelUtil.setValue(base, getExpression(base), value == null ? Object.class : 
>>> value.getClass(), value);
>>> 
>>> The problem is that the "base" map is the map containing the results and 
>>> not the "context" of the method.
>>> For example:
>>> 
>>> <set field="total" value="10" type="BigDecimal"/>
>>> <set field="result1" value="totalOrders"/>
>>> <field-to-result field="total" result-name="${result1}"/>
>>> 
>>> This should add to the output the entry: ["totalOrders": 10]
>>> 
>>> It instead throws the error because the ${result1} is expanded using the 
>>> "result" map rather than the "context" map where the "result1" field is set.
>>> 
>>> Jacopo
>>> 
>>> 
>>> On May 14, 2012, at 12:34 PM, Adrian Crum wrote:
>>> 
>>>> It must be an old bug. As far as I know, the expression parsing hasn't 
>>>> changed recently (with the exception of the recent security fix).
>>>> 
>>>> -Adrian
>>>> 
>>>> On 5/14/2012 11:27 AM, Jacopo Cappellato wrote:
>>>>> Ok, I will try to look at it and find a fix... do you have any idea about 
>>>>> why the content of the brackets is removed during parsing? Is it related 
>>>>> to recent changes or it is an old bug? They may be silly questions but I 
>>>>> actually don't know much about this code.
>>>>> 
>>>>> Jacopo
>>>>> 
>>>>> On May 14, 2012, at 12:03 PM, Adrian Crum wrote:
>>>>> 
>>>>>> That is a nested expression: The result name is contained in the 
>>>>>> variable named "key".
>>>>>> 
>>>>>> UEL does not support nested expressions, but we make it work in 
>>>>>> FlexibleStringExpander by pre-parsing the String and extracting nested 
>>>>>> expressions.
>>>>>> 
>>>>>> In addition, FlexibleMapAccessor contains some code to handle nested 
>>>>>> expressions (line 66 and 192). So, maybe that code can be improved to be 
>>>>>> smarter.
>>>>>> 
>>>>>> -Adrian
>>>>>> 
>>>>>> On 5/14/2012 10:37 AM, Jacopo Cappellato wrote:
>>>>>>> Hi Adrian,
>>>>>>> 
>>>>>>> we have noticed that the following instruction:
>>>>>>> 
>>>>>>> <field-to-result field="val" result-name="${key}"/>
>>>>>>> 
>>>>>>> (from ContentServices.xml) returns an error in the console:
>>>>>>> 
>>>>>>> 2012-05-14 14:12:02,679 (default-invoker-Thread-11) 
>>>>>>> [FlexibleMapAccessor.java:163:ERROR] UEL exception while setting value: 
>>>>>>> javax.el.ELException: Error parsing '${}': syntax error at position 2, 
>>>>>>> encountered '}', 
>>>>>>> expected<IDENTIFIER>|<STRING>|<FLOAT>|<INTEGER>|'true'|'false'|'null'|'-'|'!'|'not'|'empty'|'(',
>>>>>>>  original = ${key}
>>>>>>> 
>>>>>>> However it seems that the value is still returned properly. Any idea of 
>>>>>>> how we could fix it?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Jacopo
>>>>>>> 
>>>>>>> 
>>>>>>> 

Reply via email to