myfaces-dev mailing list archives

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



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

Mime
View raw message