myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <bernd.bohm...@atanion.com>
Subject Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
Date Thu, 22 Sep 2011 07:53:18 GMT
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 <struberg@yahoo.de> 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 <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