[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109322#comment-13109322
]
Michael Kurz commented on MYFACES-2552:
---
Continued discussion from MyFaces-3311.
+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
+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
+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.k...@gmx.at wrote:
+1
Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
+1
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
+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.gr...@gmail.com wrote:
+1 if it's configurable in a
[
https://issues.apache.org/jira/browse/MYFACES-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3262:
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109619#comment-13109619
]
Matt Benson commented on MYFACES-2552:
--
It's not technically considered a bug, but
+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 rdebussc...@gmail.com
+1
And if we create a
+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.petra...@gmail.com wrote:
[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109672#comment-13109672
]
Michael Kurz commented on MYFACES-2552:
---
It's no real issue for me at present and
+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
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
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
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
Calculation of redirect URL does not preserve the extension used in Faces
Servlet mapping
-
Key: MYFACES-3313
URL: https://issues.apache.org/jira/browse/MYFACES-3313
[
https://issues.apache.org/jira/browse/MYFACES-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109778#comment-13109778
]
Deryk Sinotte commented on MYFACES-3313:
The issue is consistent when using
+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
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
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
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 jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc: gudnabr...@gmail.com
Sent: Wednesday,
20 matches
Mail list logo
