26 messages in org.apache.myfaces.devRe: [VOTE] fix MYFACES-2552 for 2.0.x...| From | Sent On | Attachments |
|---|---|---|
| Leonardo Uribe | Sep 21, 2011 5:19 am | |
| Leonardo Uribe | Sep 21, 2011 5:20 am | |
| Michael Kurz | Sep 21, 2011 5:34 am | |
| Grant Smith | Sep 21, 2011 8:07 am | |
| Rudy De Busscher | Sep 21, 2011 8:14 am | |
| Gerhard Petracek | Sep 21, 2011 9:18 am | |
| Matt Benson | Sep 21, 2011 9:28 am | |
| Mark Struberg | Sep 21, 2011 10:47 am | |
| Mark Struberg | Sep 21, 2011 10:49 am | |
| Leonardo Uribe | Sep 21, 2011 11:11 am | |
| Leonardo Uribe | Sep 21, 2011 11:31 am | |
| Jakob Korherr | Sep 21, 2011 1:20 pm | |
| Grant Smith | Sep 21, 2011 1:42 pm | |
| Matt Benson | Sep 21, 2011 2:01 pm | |
| Mark Struberg | Sep 21, 2011 2:50 pm | |
| Bernd Bohmann | Sep 22, 2011 12:52 am | |
| Gerhard Petracek | Sep 22, 2011 12:58 am | |
| Martin Marinschek | Sep 22, 2011 1:17 am | |
| Jakob Korherr | Sep 22, 2011 3:15 am | |
| Michael Kurz | Sep 22, 2011 4:14 am | |
| Mark Struberg | Sep 22, 2011 4:17 am | |
| Michael Kurz | Sep 22, 2011 4:29 am | |
| Bernd Bohmann | Sep 22, 2011 5:15 am | |
| Michael Kurz | Sep 22, 2011 5:22 am | |
| Leonardo Uribe | Sep 22, 2011 7:10 am | |
| Grant Smith | Sep 22, 2011 7:59 am |
| Subject: | Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches | |
|---|---|---|
| From: | Leonardo Uribe (lu4...@gmail.com) | |
| Date: | Sep 22, 2011 7:10:20 am | |
| List: | org.apache.myfaces.dev | |
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 <mich...@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 <mich...@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<mich...@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<mmar...@apache.org>:
+1 in general, +1 to Bernd's suggestion.
best regards,
Martin
On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek <gerh...@gmail.com> wrote:
@bernd: +1 regards, gerhard
Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Professional Support for Apache MyFaces
2011/9/22 Bernd Bohmann<bern...@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<stru...@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 -----
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<lu4...@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<lu4...@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<stru...@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<gudn...@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
<gerh...@gmail.com>
wrote:
+1 for it in combination with
the context parameter
regards, gerhard
Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Professional Support for Apache
MyFaces
2011/9/21 Rudy De
Busscher<rdeb...@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...@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
<mich...@gmx.at> wrote:
+1
Am 21.09.2011 um
14:20 schrieb Leonardo Uribe:
> +1 > > 2011/9/21
Leonardo Uribe
<lu4...@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
--
Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Professional Support for Apache MyFaces