+1 for it in combination with the context 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/9/21 Rudy De Busscher <[email protected]> > +1 > And if we create a context parameter, it should behave by default as in the > JSF 2.2 Spec. If users want strict spec (2.0/2.1)behaviour they have to set > the parameter value. > regards > Rudy > On 21 September 2011 17:08, Grant Smith <[email protected]> wrote: > >> +1 if it's configurable in a <context-param>. How about >> org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ? >> >> On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz <[email protected]> wrote: >> >>> +1 >>> >>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe: >>> >>> > +1 >>> > >>> > 2011/9/21 Leonardo Uribe <[email protected]>: >>> >> Hi >>> >> >>> >> More than a year ago, it was found that EL expressions like >>> >> #{cc.attrs.test} does not resolve its type correctly, because the >>> >> composite component EL resolver is not able to find the right type. >>> >> Instead, MapELResolver always return Object.class as type, breaking >>> >> composite components that use h:selectOneXXX into its internals. See >>> >> >>> >> https://issues.apache.org/jira/browse/MYFACES-2552 >>> >> >>> >> The problem with this issue is we need to change the way how >>> >> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver >>> >> works. JSF 2.0 spec clearly says in its section 5.6.2.2 that getType() >>> >> for that EL resolver should return null. >>> >> >>> >> The issue was reported to the EG and a fix was included in JSF 2.2. >>> spec, see: >>> >> >>> >> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745 >>> >> >>> >> but we still receive reports about the same issue (MYFACES-3311 and >>> >> others (last comment on MYFACES-1890) ). >>> >> >>> >> So, the current behavior even if is described by the spec is too >>> >> inconvenient. Note we already have some places in our implementation >>> >> that does not follow strictly the spec, to keep things working as >>> >> users expect. To follow the protocol in these cases, we need an >>> >> official community decision about include it in 2.0.x and 2.1.x >>> >> branches. Please vote: >>> >> >>> >> +1 if you want this fix included in 2.0.x and 2.1.x. >>> >> +0 >>> >> -1 and the reason why if you see this could cause any problem. >>> >> >>> >> regards, >>> >> >>> >> Leonardo Uribe >>> >> >>> >> [1] http://www.apache.org/foundation/voting.html#ReleaseVotes >>> >> >>> >>> >> >> >> -- >> Grant Smith - V.P. Information Technology >> Marathon Computer Systems, LLC. >> >> > > > -- > Rudy De Busscher > http://www.c4j.be > >
