@bernd: +1 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/22 Bernd Bohmann <[email protected]> > I agree STRICT_JSF_2_COMPATIBILITY is too generic. I think the param > should contain EL, TYPE, MAP, RESOLVER, NULL. And it should enabled by > default. > > Regards > > Bernd > > On Wed, Sep 21, 2011 at 11:50 PM, Mark Struberg <[email protected]> wrote: > > Shouldnt the config contain the text EL_TYPE or so? > > We have far too many strict JSF spec flags already ;) > > > > LieGrue, > > strub > > > > > > > > ----- Original Message ----- > >> From: Jakob Korherr <[email protected]> > >> To: MyFaces Development <[email protected]> > >> Cc: [email protected] > >> Sent: Wednesday, September 21, 2011 10:20 PM > >> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches > >> > >> +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 <[email protected]>: > >>> 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 <[email protected]>: > >>>> 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 <[email protected]>: > >>>>> 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 <[email protected]> > >>>>>> To: MyFaces Development <[email protected]> > >>>>>> 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 > >>>>>> <[email protected]> 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 <[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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > >> > >> -- > >> Jakob Korherr > >> > >> blog: http://www.jakobk.com > >> twitter: http://twitter.com/jakobkorherr > >> work: http://www.irian.at > >> > > >
