Gerhard,

And after a discussion with Matt, I'm convinced that the current code is
even wrong.  Since the EL stuff should be independent of JSF.  The only
correct way is using the ELResolver from the method parameter.

I'll commit the patch from Matt (MYFACESTEST-51) on Monday.

Thx
Regards

On 27 May 2011 17:31, Gerhard Petracek <gerhard.petra...@gmail.com> wrote:

> hi rudy,
>
> extval as well as other libs create and activate a custom el-resolver just
> for a specific call. this approach is quite old and works with both jsf
> implementations.
> if there is an issue with the mock code, we just have to change it. there
> is no reason for not using the el-resolver from the parameter.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/5/27 Rudy De Busscher <rdebussc...@gmail.com>
>
>> Hi All,
>>
>> In the MyFacesTest project, we have a mock implementation of the
>> ValueExpression.getValue() method, see
>> org.apache.myfaces.test.el.MockValueExpression#getValue.
>>
>> That method has an javax.el.ELContext parameter, that contains a reference
>> to the ELResolver.  However, in the method, we use the ELResolver from the
>> Application object (
>> FacesContext.getCurrentInstance().getApplication().getELResolver() ) and not
>> the one passed in as method parameter.
>>
>> I found in the specs that both should reference to the same instance but
>> in ExtVal we have an ExtValELResolver.  And Matt found out (see EXTVAL-133
>> and MYFACESTEST-51) that they are not the same in the tests of ExtVal 2.0.x.
>> (ExtValELResolver in parameter but std ELResolver in Application object)
>>
>> So my question now is (since those lines of codes aren't changed since the
>> Shale test import) : Could there be any conflict/misbehaviour/etc ... when
>> we use the ELResolver from the parameter instead of the one from the
>> FacesContext??
>>
>> Myfaces core (https://svn.apache.org/repos/asf/myfaces/core/trunk)
>> doesn't break with the change.
>>
>> Thx for your feedback
>> Rudy.
>>
>>
>>
>

Reply via email to