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 <[email protected]> > 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. > > >
