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 Thu, 22 Sep 2011 11:17:31 GMT
of course there is:

http://myfaces.apache.org/core20/myfaces-impl/webconfig.html

LieGrue,
strub



----- Original Message -----
> From: Michael Kurz <michi.kurz@gmx.at>
> To: MyFaces Development <dev@myfaces.apache.org>
> Cc: 
> Sent: Thursday, September 22, 2011 1:14 PM
> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
> 
> 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