[VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Leonardo Uribe <lu...@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

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Matt Benson <gu...@gmail.com>]

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 <wo...@gmail.com> 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 <ja...@gmail.com>
> 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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>> >>>> To: MyFaces Development <de...@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
>> >>>> <ge...@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 <rd...@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 <wo...@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
>> >>>> <mi...@gmx.at> wrote:
>> >>>>>>>>
>> >>>>>>>>  +1
>> >>>>>>>>
>> >>>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>> >>>>>>>>
>> >>>>>>>>  > +1
>> >>>>>>>>  >
>> >>>>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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
>
>
>
> --
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Grant Smith <wo...@gmail.com>]

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 <ja...@gmail.com>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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
> >>>> To: MyFaces Development <de...@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
> >>>> <ge...@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 <rd...@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 <wo...@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
> >>>> <mi...@gmx.at> wrote:
> >>>>>>>>
> >>>>>>>>  +1
> >>>>>>>>
> >>>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
> >>>>>>>>
> >>>>>>>>  > +1
> >>>>>>>>  >
> >>>>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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
>



-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Grant Smith <wo...@gmail.com>]

> Ok, so can we agree on use a name like
> org.apache.myfaces.STRICT_JSF_2_EL_RESOLVER_COMPATIBILITY?--
>

I would say yes, so that it leaves space for possible
org.apache.myfaces.STRICT_JSF_* parameters in the future.


Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Leonardo Uribe <lu...@gmail.com>]

Hi

Ok, so can we agree on use a name like
org.apache.myfaces.STRICT_JSF_2_EL_RESOLVER_COMPATIBILITY?

I strongly suggest the default value of this param should be "false"
by the following reasons:

1. I don't believe the TCK check this specific part. Only if the
change cause a test to fail, we are forced to set the param by default
to "true".
2. If somebody needs to change from myfaces to mojarra by some reason,
it is possible to create a fix without change mojarra internals (a
custom EL resolver), keeping interoperability between both jsf
implementations. Implementors of composite component libraries can
include a fix, but if we include it on myfaces, checking the version
and the param they can decide if the resolver needs to return
something different than null on getType() or not.
3. Users see this issue as a problem over the implementation. Enabling
the fix over getType() by default will make users happier, because its
composite components that relies on this effect will work as expected.
4. In practice, only (very few) people interested in "strict" jsf 2
compatibility will enable this param.

regards,


Leonardo


2011/9/22 Michael Kurz <mi...@gmx.at>:
> +1 :)
>
> Am 22.09.2011 um 14:15 schrieb Bernd Bohmann:
>
>> Sorry I suggested to enable this parameter as default
>> You only need to know this parameter if you need the old behavoir
>>
>> Regards
>>
>> Bernd
>>
>> On Thu, Sep 22, 2011 at 1:30 PM, Michael Kurz <mi...@gmx.at> wrote:
>>> OK, good. But: This would then be parameter 94 to consider?
>>>
>>> Best regards
>>> Michi
>>>
>>> Am 22.09.2011 13:17, schrieb Mark Struberg:
>>>>
>>>> of course there is:
>>>>
>>>> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>> From: Michael Kurz<mi...@gmx.at>
>>>>> To: MyFaces Development<de...@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<mm...@apache.org>:
>>>>>>>
>>>>>>>  +1 in general, +1 to Bernd's suggestion.
>>>>>>>
>>>>>>>  best regards,
>>>>>>>
>>>>>>>  Martin
>>>>>>>
>>>>>>>  On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>>>>>>>  <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>>>>>>>  To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    To: MyFaces
>>>>>
>>>>> Development<de...@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    <ge...@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<rd...@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
>>>>>>>>>>>
>>>>>>>>>>>  <wo...@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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    <mi...@gmx.at>   wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     +1
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     Am 21.09.2011 um
>>>>>
>>>>> 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     >   +1
>>>>>>>>>>>>>>>>>>>     >
>>>>>>>>>>>>>>>>>>>     >   2011/9/21
>>>>>
>>>>> Leonardo Uribe
>>>>>>>>>>>
>>>>>>>>>>>  <lu...@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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Michael Kurz <mi...@gmx.at>]

+1 :)

Am 22.09.2011 um 14:15 schrieb Bernd Bohmann:

> Sorry I suggested to enable this parameter as default
> You only need to know this parameter if you need the old behavoir
> 
> Regards
> 
> Bernd
> 
> On Thu, Sep 22, 2011 at 1:30 PM, Michael Kurz <mi...@gmx.at> wrote:
>> OK, good. But: This would then be parameter 94 to consider?
>> 
>> Best regards
>> Michi
>> 
>> Am 22.09.2011 13:17, schrieb Mark Struberg:
>>> 
>>> of course there is:
>>> 
>>> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> 
>>>> From: Michael Kurz<mi...@gmx.at>
>>>> To: MyFaces Development<de...@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<mm...@apache.org>:
>>>>>> 
>>>>>>  +1 in general, +1 to Bernd's suggestion.
>>>>>> 
>>>>>>  best regards,
>>>>>> 
>>>>>>  Martin
>>>>>> 
>>>>>>  On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>>>>>>  <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>>>>>>  To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>    To: MyFaces
>>>> 
>>>> Development<de...@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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>    <ge...@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<rd...@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
>>>>>>>>>> 
>>>>>>>>>>  <wo...@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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>    <mi...@gmx.at>   wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>     +1
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>     Am 21.09.2011 um
>>>> 
>>>> 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>     >   +1
>>>>>>>>>>>>>>>>>>     >
>>>>>>>>>>>>>>>>>>     >   2011/9/21
>>>> 
>>>> Leonardo Uribe
>>>>>>>>>> 
>>>>>>>>>>  <lu...@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
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Bernd Bohmann <be...@atanion.com>]

Sorry I suggested to enable this parameter as default
You only need to know this parameter if you need the old behavoir

Regards

Bernd

On Thu, Sep 22, 2011 at 1:30 PM, Michael Kurz <mi...@gmx.at> wrote:
> OK, good. But: This would then be parameter 94 to consider?
>
> Best regards
> Michi
>
> Am 22.09.2011 13:17, schrieb Mark Struberg:
>>
>> of course there is:
>>
>> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>>
>>> From: Michael Kurz<mi...@gmx.at>
>>> To: MyFaces Development<de...@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<mm...@apache.org>:
>>>>>
>>>>>  +1 in general, +1 to Bernd's suggestion.
>>>>>
>>>>>  best regards,
>>>>>
>>>>>  Martin
>>>>>
>>>>>  On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>>>>>  <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>>>>>  To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    To: MyFaces
>>>
>>> Development<de...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>    <ge...@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<rd...@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
>>>>>>>>>
>>>>>>>>>  <wo...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>    <mi...@gmx.at>   wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     +1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Am 21.09.2011 um
>>>
>>> 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     >   +1
>>>>>>>>>>>>>>>>>     >
>>>>>>>>>>>>>>>>>     >   2011/9/21
>>>
>>> Leonardo Uribe
>>>>>>>>>
>>>>>>>>>  <lu...@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
>>>>>
>>>>
>>>>
>>>>
>>>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Michael Kurz <mi...@gmx.at>]

OK, good. But: This would then be parameter 94 to consider?

Best regards
Michi

Am 22.09.2011 13:17, schrieb Mark Struberg:
> of course there is:
>
> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Michael Kurz<mi...@gmx.at>
>> To: MyFaces Development<de...@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<mm...@apache.org>:
>>>>   +1 in general, +1 to Bernd's suggestion.
>>>>
>>>>   best regards,
>>>>
>>>>   Martin
>>>>
>>>>   On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>>>>   <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>>>>   To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>>>     To: MyFaces
>> Development<de...@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
>>>>>>>>>>>>     <ge...@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<rd...@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
>>>>>>>>   <wo...@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
>>>>>>>>>>>>     <mi...@gmx.at>   wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      +1
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      Am 21.09.2011 um
>> 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      >   +1
>>>>>>>>>>>>>>>>      >
>>>>>>>>>>>>>>>>      >   2011/9/21
>> Leonardo Uribe
>>>>>>>>   <lu...@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
>>>>
>>>
>>>
>>>
>>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Mark Struberg <st...@yahoo.de>]

of course there is:

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

LieGrue,
strub



----- Original Message -----
> From: Michael Kurz <mi...@gmx.at>
> To: MyFaces Development <de...@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<mm...@apache.org>:
>>>  +1 in general, +1 to Bernd's suggestion.
>>> 
>>>  best regards,
>>> 
>>>  Martin
>>> 
>>>  On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>>>  <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>>>  To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>>    To: MyFaces 
> Development<de...@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
>>>>>>>>>>>    <ge...@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<rd...@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
>>>>>>>  <wo...@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
>>>>>>>>>>>    <mi...@gmx.at>  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>     +1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>     Am 21.09.2011 um 
> 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>     >  +1
>>>>>>>>>>>>>>>     >
>>>>>>>>>>>>>>>     >  2011/9/21 
> Leonardo Uribe
>>>>>>>  <lu...@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
>>> 
>> 
>> 
>> 
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Michael Kurz <mi...@gmx.at>]

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<mm...@apache.org>:
>> +1 in general, +1 to Bernd's suggestion.
>>
>> best regards,
>>
>> Martin
>>
>> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
>> <ge...@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<be...@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<st...@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<ja...@gmail.com>
>>>>>> To: MyFaces Development<de...@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<lu...@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<lu...@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<st...@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<gu...@gmail.com>
>>>>>>>>>>   To: MyFaces Development<de...@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
>>>>>>>>>>   <ge...@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<rd...@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
>>>>>> <wo...@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
>>>>>>>>>>   <mi...@gmx.at>  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    +1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    >  +1
>>>>>>>>>>>>>>    >
>>>>>>>>>>>>>>    >  2011/9/21 Leonardo Uribe
>>>>>> <lu...@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
>>
>
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Jakob Korherr <ja...@gmail.com>]

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 <mm...@apache.org>:
> +1 in general, +1 to Bernd's suggestion.
>
> best regards,
>
> Martin
>
> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
> <ge...@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 <be...@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 <st...@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 <ja...@gmail.com>
>>> >> To: MyFaces Development <de...@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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>>> >>>>>>  To: MyFaces Development <de...@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
>>> >>>>>>  <ge...@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 <rd...@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
>>> >> <wo...@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
>>> >>>>>>  <mi...@gmx.at> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>>   +1
>>> >>>>>>>>>>
>>> >>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>> >>>>>>>>>>
>>> >>>>>>>>>>   > +1
>>> >>>>>>>>>>   >
>>> >>>>>>>>>>   > 2011/9/21 Leonardo Uribe
>>> >> <lu...@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
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Martin Marinschek <mm...@apache.org>]

+1 in general, +1 to Bernd's suggestion.

best regards,

Martin

On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
<ge...@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 <be...@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 <st...@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 <ja...@gmail.com>
>> >> To: MyFaces Development <de...@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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>> >>>>>>  To: MyFaces Development <de...@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
>> >>>>>>  <ge...@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 <rd...@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
>> >> <wo...@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
>> >>>>>>  <mi...@gmx.at> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>   +1
>> >>>>>>>>>>
>> >>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>> >>>>>>>>>>
>> >>>>>>>>>>   > +1
>> >>>>>>>>>>   >
>> >>>>>>>>>>   > 2011/9/21 Leonardo Uribe
>> >> <lu...@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

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Gerhard Petracek <ge...@gmail.com>]

@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 <be...@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 <st...@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 <ja...@gmail.com>
> >> To: MyFaces Development <de...@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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
> >>>>>>  To: MyFaces Development <de...@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
> >>>>>>  <ge...@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 <rd...@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
> >> <wo...@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
> >>>>>>  <mi...@gmx.at> wrote:
> >>>>>>>>>>
> >>>>>>>>>>   +1
> >>>>>>>>>>
> >>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
> >>>>>>>>>>
> >>>>>>>>>>   > +1
> >>>>>>>>>>   >
> >>>>>>>>>>   > 2011/9/21 Leonardo Uribe
> >> <lu...@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
> >>
> >
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Bernd Bohmann <be...@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 <st...@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 <ja...@gmail.com>
>> To: MyFaces Development <de...@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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>>>>>>  To: MyFaces Development <de...@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
>>>>>>  <ge...@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 <rd...@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
>> <wo...@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
>>>>>>  <mi...@gmx.at> wrote:
>>>>>>>>>>
>>>>>>>>>>   +1
>>>>>>>>>>
>>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>>>>
>>>>>>>>>>   > +1
>>>>>>>>>>   >
>>>>>>>>>>   > 2011/9/21 Leonardo Uribe
>> <lu...@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
>>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Mark Struberg <st...@yahoo.de>]

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 <ja...@gmail.com>
> To: MyFaces Development <de...@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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>>>>>  To: MyFaces Development <de...@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
>>>>>  <ge...@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 <rd...@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 
> <wo...@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
>>>>>  <mi...@gmx.at> wrote:
>>>>>>>>> 
>>>>>>>>>   +1
>>>>>>>>> 
>>>>>>>>>   Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>>> 
>>>>>>>>>   > +1
>>>>>>>>>   >
>>>>>>>>>   > 2011/9/21 Leonardo Uribe 
> <lu...@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
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Jakob Korherr <ja...@gmail.com>]

+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 <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>>>> To: MyFaces Development <de...@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
>>>> <ge...@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 <rd...@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 <wo...@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
>>>> <mi...@gmx.at> wrote:
>>>>>>>>
>>>>>>>>  +1
>>>>>>>>
>>>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>>
>>>>>>>>  > +1
>>>>>>>>  >
>>>>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Leonardo Uribe <lu...@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 <lu...@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 <st...@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 <gu...@gmail.com>
>>> To: MyFaces Development <de...@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
>>> <ge...@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 <rd...@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 <wo...@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
>>> <mi...@gmx.at> wrote:
>>>>>>>
>>>>>>>  +1
>>>>>>>
>>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>
>>>>>>>  > +1
>>>>>>>  >
>>>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Leonardo Uribe <lu...@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 <st...@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 <gu...@gmail.com>
>> To: MyFaces Development <de...@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
>> <ge...@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 <rd...@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 <wo...@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
>> <mi...@gmx.at> wrote:
>>>>>>
>>>>>>  +1
>>>>>>
>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>
>>>>>>  > +1
>>>>>>  >
>>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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
>>>>
>>>
>>>
>>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Mark Struberg <st...@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 <gu...@gmail.com>
> To: MyFaces Development <de...@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
> <ge...@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 <rd...@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 <wo...@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 
> <mi...@gmx.at> wrote:
>>>>> 
>>>>>  +1
>>>>> 
>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>> 
>>>>>  > +1
>>>>>  >
>>>>>  > 2011/9/21 Leonardo Uribe <lu...@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
>>> 
>> 
>> 
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Matt Benson <gu...@gmail.com>]

+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
<ge...@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 <rd...@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 <wo...@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 <mi...@gmx.at> wrote:
>>>>
>>>> +1
>>>>
>>>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>
>>>> > +1
>>>> >
>>>> > 2011/9/21 Leonardo Uribe <lu...@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
>>
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Gerhard Petracek <ge...@gmail.com>]

+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 <rd...@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 <wo...@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 <mi...@gmx.at> wrote:
>>
>>> +1
>>>
>>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>
>>> > +1
>>> >
>>> > 2011/9/21 Leonardo Uribe <lu...@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
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Rudy De Busscher <rd...@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 <wo...@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 <mi...@gmx.at> wrote:
>
>> +1
>>
>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>
>> > +1
>> >
>> > 2011/9/21 Leonardo Uribe <lu...@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

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Mark Struberg <st...@yahoo.de>]

+1

In general for fixing this issue. I'm not firm with the current spec version though. Would we do it the same way as it is planed for 2.2 or is the spec a step behind?


In any case introducing a Context param for configuring the behaviour is a good idea.

LieGrue,
strub




>________________________________
>From: Grant Smith <wo...@gmail.com>
>To: MyFaces Development <de...@myfaces.apache.org>
>Sent: Wednesday, September 21, 2011 5:08 PM
>Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
>
>
>+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 <mi...@gmx.at> wrote:
>
>+1
>>
>>Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>
>>
>>> +1
>>>
>>> 2011/9/21 Leonardo Uribe <lu...@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.
>
>
>
>

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Grant Smith <wo...@gmail.com>]

+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 <mi...@gmx.at> wrote:

> +1
>
> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>
> > +1
> >
> > 2011/9/21 Leonardo Uribe <lu...@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.

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Michael Kurz <mi...@gmx.at>]

+1

Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:

> +1
> 
> 2011/9/21 Leonardo Uribe <lu...@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
>> 

Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches

[Leonardo Uribe <lu...@gmail.com>]

+1

2011/9/21 Leonardo Uribe <lu...@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
>