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: | Grant Smith (work...@gmail.com) | |
| Date: | Sep 21, 2011 1:42:34 pm | |
| List: | org.apache.myfaces.dev | |
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 <jako...@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 <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
-- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.