myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
Date Wed, 21 Sep 2011 21:50:33 GMT
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 <jakob.korherr@gmail.com>
> To: MyFaces Development <dev@myfaces.apache.org>
> Cc: gudnabrsam@gmail.com
> 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 <lu4242@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 <lu4242@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 <struberg@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 <gudnabrsam@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.petracek@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 <rdebusscher@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.grant@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.kurz@gmx.at> wrote:
>>>>>>>>> 
>>>>>>>>>   +1
>>>>>>>>> 
>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>>> 
>>>>>>>>>   > +1
>>>>>>>>>   >
>>>>>>>>>   > 2011/9/21 Leonardo Uribe 
> <lu4242@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
>

Mime
View raw message