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 >>>>> >>>> >>>> >>> >> >
