My only problem with calling it org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY is that it's pretty generic. What if there are other behaviors that come up in the future that also break strict compatibility ? Do we lump them all under one umbrella ?
How about appending _EL_RESOLVER to make it (more) specific... On Wed, Sep 21, 2011 at 1:20 PM, Jakob Korherr <jakob.korh...@gmail.com>wrote: > +1 for including the fix in 2.0.x and 2.1.x + adding > org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY > > Regards, > Jakob > > 2011/9/21 Leonardo Uribe <lu4...@gmail.com>: > > Hi > > > > @Matt Benson: Could you attach at least the fragment with the solution > > for MYFACES-2552 ? so I can check it, create a patch for myfaces and > > write a page on: > > > > https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components > > > > with the explanation and the solution using a custom EL resolver. That > > would be very helpful. > > > > regards, > > > > Leonardo Uribe > > > > 2011/9/21 Leonardo Uribe <lu4...@gmail.com>: > >> Hi > >> > >> It should be a param starting with org.apache.myfaces, like > >> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY > >> > >> The important part is that by default it should be disabled, to > >> prevent receive over and over the same report. > >> > >> In theory, it is possible to write a custom EL resolver that check if > >> the base object implements > >> javax.faces.el.CompositeComponentExpressionHolder and if that so, do > >> the required stuff only on getType(). So, if somebody is writing a > >> composite component that relies on this behavior, it is possible to > >> write the fix in a portable way to both Mojarra and MyFaces (thanks to > >> CompositeComponentExpressionHolder). > >> > >> Note the change does not cause any side effects, because nobody relies > >> on the "wrong" behavior, and what user wants is components work as > >> expected. > >> > >> regards, > >> > >> Leonardo Uribe > >> > >> 2011/9/21 Mark Struberg <strub...@yahoo.de>: > >>> Not sure about that. > >>> Does the param start with javax.faces? In this case we should rather > use an own internal one. > >>> > >>> Btw, if it's not in the spec even Mojarra would not be allowed to use a > proprietary parameter with "javax...." > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: Matt Benson <gudnabr...@gmail.com> > >>>> To: MyFaces Development <dev@myfaces.apache.org> > >>>> Cc: > >>>> Sent: Wednesday, September 21, 2011 6:29 PM > >>>> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches > >>>> > >>>> +1 > >>>> > >>>> However, let's simplify the context parameter by giving it a name > >>>> relating to JSF 2.2 compatibility. I submitted the final > >>>> implementation for Mojarra, so have every right to add the same to > >>>> MyFaces. > >>>> > >>>> Matt > >>>> > >>>> On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek > >>>> <gerhard.petra...@gmail.com> wrote: > >>>>> +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 <rdebussc...@gmail.com> > >>>>>> > >>>>>> +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 <work.gr...@gmail.com> > >>>> 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 > >>>> <michi.k...@gmx.at> wrote: > >>>>>>>> > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe: > >>>>>>>> > >>>>>>>> > +1 > >>>>>>>> > > >>>>>>>> > 2011/9/21 Leonardo Uribe <lu4...@gmail.com>: > >>>>>>>> >> 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 > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
