myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
Date Wed, 21 Sep 2011 18:31:52 GMT
Hi

@Matt Benson: Could you attach at least the fragment with the solution
for MYFACES-2552 ? so I can check it, create a patch for myfaces and
write a page on:

https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components

with the explanation and the solution using a custom EL resolver. That
would be very helpful.

regards,

Leonardo Uribe

2011/9/21 Leonardo Uribe <lu4242@gmail.com>:
> Hi
>
> It should be a param starting with org.apache.myfaces, like
> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY
>
> The important part is that by default it should be disabled, to
> prevent receive over and over the same report.
>
> In theory, it is possible to write a custom EL resolver that check if
> the base object implements
> javax.faces.el.CompositeComponentExpressionHolder and if that so, do
> the required stuff only on getType(). So, if somebody is writing a
> composite component that relies on this behavior, it is possible to
> write the fix in a portable way to both Mojarra and MyFaces (thanks to
> CompositeComponentExpressionHolder).
>
> Note the change does not cause any side effects, because nobody relies
> on the "wrong" behavior, and what user wants is components work as
> expected.
>
> regards,
>
> Leonardo Uribe
>
> 2011/9/21 Mark Struberg <struberg@yahoo.de>:
>> Not sure about that.
>> Does the param start with javax.faces? In this case we should rather use an own internal
one.
>>
>> Btw, if it's not in the spec even Mojarra would not be allowed to use a proprietary
parameter with "javax...."
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Matt Benson <gudnabrsam@gmail.com>
>>> To: MyFaces Development <dev@myfaces.apache.org>
>>> Cc:
>>> Sent: Wednesday, September 21, 2011 6:29 PM
>>> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
>>>
>>> +1
>>>
>>> However, let's simplify the context parameter by giving it a name
>>> relating to JSF 2.2 compatibility.  I submitted the final
>>> implementation for Mojarra, so have every right to add the same to
>>> MyFaces.
>>>
>>> Matt
>>>
>>> On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek
>>> <gerhard.petracek@gmail.com> wrote:
>>>>  +1 for it in combination with the context parameter
>>>>  regards,
>>>>  gerhard
>>>>
>>>>  http://www.irian.at
>>>>
>>>>  Your JSF powerhouse -
>>>>  JSF Consulting, Development and
>>>>  Courses in English and German
>>>>
>>>>  Professional Support for Apache MyFaces
>>>>
>>>>
>>>>
>>>>  2011/9/21 Rudy De Busscher <rdebusscher@gmail.com>
>>>>>
>>>>>  +1
>>>>>  And if we create a context parameter, it should behave by default as
in
>>>>>  the JSF 2.2 Spec.  If users want strict spec (2.0/2.1)behaviour they
>>> have to
>>>>>  set the parameter value.
>>>>>  regards
>>>>>  Rudy
>>>>>  On 21 September 2011 17:08, Grant Smith <work.grant@gmail.com>
>>> wrote:
>>>>>>
>>>>>>  +1 if it's configurable in a <context-param>. How about
>>>>>>  org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ?
>>>>>>
>>>>>>  On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz
>>> <michi.kurz@gmx.at> wrote:
>>>>>>>
>>>>>>>  +1
>>>>>>>
>>>>>>>  Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>>>>>>
>>>>>>>  > +1
>>>>>>>  >
>>>>>>>  > 2011/9/21 Leonardo Uribe <lu4242@gmail.com>:
>>>>>>>  >> Hi
>>>>>>>  >>
>>>>>>>  >> More than a year ago, it was found that EL expressions
>>> like
>>>>>>>  >> #{cc.attrs.test} does not resolve its type correctly,
>>> because the
>>>>>>>  >> composite component EL resolver is not able to find
>>> the right type.
>>>>>>>  >> Instead, MapELResolver always return Object.class
as
>>> type, breaking
>>>>>>>  >> composite components that use h:selectOneXXX into
its
>>> internals. See
>>>>>>>  >>
>>>>>>>  >> https://issues.apache.org/jira/browse/MYFACES-2552
>>>>>>>  >>
>>>>>>>  >> The problem with this issue is we need to change the
>>> way how
>>>>>>>  >>
>>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver
>>>>>>>  >> works. JSF 2.0 spec clearly says in its section
>>> 5.6.2.2 that
>>>>>>>  >> getType()
>>>>>>>  >> for that EL resolver should return null.
>>>>>>>  >>
>>>>>>>  >> The issue was reported to the EG and a fix was
>>> included in JSF 2.2.
>>>>>>>  >> spec, see:
>>>>>>>  >>
>>>>>>>  >>
>>> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745
>>>>>>>  >>
>>>>>>>  >> but we still receive reports about the same issue
>>> (MYFACES-3311 and
>>>>>>>  >> others (last comment on MYFACES-1890) ).
>>>>>>>  >>
>>>>>>>  >> So, the current behavior even if is described by the
>>> spec is too
>>>>>>>  >> inconvenient. Note we already have some places in
our
>>> implementation
>>>>>>>  >> that does not follow strictly the spec, to keep things
>>> working as
>>>>>>>  >> users expect. To follow the protocol in these cases,
>>> we need an
>>>>>>>  >> official community decision about include it in 2.0.x
>>> and 2.1.x
>>>>>>>  >> branches. Please vote:
>>>>>>>  >>
>>>>>>>  >> +1 if you want this fix included in 2.0.x and 2.1.x.
>>>>>>>  >> +0
>>>>>>>  >> -1 and the reason why if you see this could cause
any
>>> problem.
>>>>>>>  >>
>>>>>>>  >> regards,
>>>>>>>  >>
>>>>>>>  >> Leonardo Uribe
>>>>>>>  >>
>>>>>>>  >> [1]
>>> http://www.apache.org/foundation/voting.html#ReleaseVotes
>>>>>>>  >>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>>  Grant Smith - V.P. Information Technology
>>>>>>  Marathon Computer Systems, LLC.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  Rudy De Busscher
>>>>>  http://www.c4j.be
>>>>>
>>>>
>>>>
>>>
>>
>

Mime
View raw message