The spec issue at hand relates, ultimately, to the implementation of getType() against the composite components attributes map ELResolver. The workaround presented in JIRA involves a pluggable ELResolver that delegates getType() to a ValueExpression found for a given attribute; I would venture to guess this would get the job done most of the time. The final spec for 2.2 goes farther, however, by incorporating Leo's suggestion that a composite:attribute element's 'type' attribute would also be consulted. The amended spec text describing this behavior:
If the base argument to getType() is not an instance of the composite component attributes map or the property argument to getType() is not an instance of java.lang.String, return null. Otherwise, check the top level component's ValueExpression collection for an expression under the name given by the property argument to getType(). If the expression exists, call getType() on the expression. If the property argument to getType() is not empty, search the composite component's metadata for a declared type on a <composite:attribute> whose name matches the property argument to getType(). If the expression and the metadata both yield results, the metadata takes precedence ONLY if it provides a narrower result than does the expression, i.e. expression type is assignable from metadata type. Otherwise, return whichever result was available, or null. Obviously the code to implement the above will have to reside in MyFaces at some point. For this reason I would recommend the context parameter simply enable the above behavior. Matt On Wed, Sep 21, 2011 at 3:42 PM, Grant Smith <[email protected]> wrote: > 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 <[email protected]> > 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 <[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 > > > > -- > Grant Smith - V.P. Information Technology > Marathon Computer Systems, LLC. > >
