myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Kurz <michi.k...@gmx.at>
Subject Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
Date Thu, 22 Sep 2011 11:14:36 GMT
I agree with Jakob, nobody will know about a parameter like this (are 
they documented anywhere btw?). The effect (without setting it): for 
application developers JSF seems to be broken.

Best regards
Michi

Am 22.09.2011 12:16, schrieb Jakob Korherr:
> Hi,
>
> Both suggestions for a name are reasonable, because they suggest
> different things!
>
> What Leo suggested (STRICT_JSF_2_COMPATIBILITY), is the flag we
> (internally) have been discussing (and postponing) for a long time.
> This config parameter would enable us to include non-spec behavior in
> MyFaces core, which would make us fail the TCK, if we included it by
> default. However, by enabling it via config parameter only
> (STRICT_JSF_2_COMPATIBILITY=false), we would be able to fix obvious
> spec issues already in MyFaces core 2.0 (e.g. MYFACES-2552) and still
> passing the TCK. Thus we would not need to wait for the next spec
> release (which may not even contain the fix....), to fix critical
> issues.
>
> What Mark and Bernd suggested is to include the fix for MYFACES-2552
> and make a config parameter just for this behavior.
>
>
> Actually, I think introducing yet another config parameter for (in
> this case) very specific behavior is not the best idea, b/c no-one
> outside of the MyFaces developers will use it. Introducing a more
> generic config param, which would allow us to fix a lot more issues
> which are just like this one, is IMO a far better idea.
>
> Thus, my vote is +1 for STRICT_JSF_2_COMPATIBILITY and +0 for Bernd's
> suggestion.
>
> Regards,
> Jakob
>
> 2011/9/22 Martin Marinschek<mmarinschek@apache.org>:
>> +1 in general, +1 to Bernd's suggestion.
>>
>> best regards,
>>
>> Martin
>>
>> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>> <gerhard.petracek@gmail.com>  wrote:
>>> @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<bernd.bohmann@atanion.com>
>>>>
>>>> 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
>>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>
>

Mime
View raw message