Re: [VOTE] Release of MyFaces Core 2.2.3
+1 Am 22.04.2014 um 18:16 schrieb Martin Kočí martin.kocicak.k...@gmail.com: +1 2014-04-22 12:20 GMT+02:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.3 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1021/org/apache/myfaces/ https://repository.apache.org/content/repositories/orgapachemyfaces-1020/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces223binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326543
Re: [VOTE] release of MyFaces Core 2.2.3
-1 I have serious problems with version 2.2.3 provided by Leo and with the current snapshot in one of my examples. It seems, that there is some problem with resources or templates or both. The application works and looks fine with 2.2.1 and 2.2.2 but not with 2.2.3 or the current snapshot. Best regards Michi Am 11.04.2014 um 12:10 schrieb Werner Punz werner.p...@gmail.com: +1 Am 08.04.14 17:11, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.2.3 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1016/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces223binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326543
[jira] [Created] (MYFACES-3882) Page with template and stylesheet not rendered correctly
Michael Kurz created MYFACES-3882: - Summary: Page with template and stylesheet not rendered correctly Key: MYFACES-3882 URL: https://issues.apache.org/jira/browse/MYFACES-3882 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.3 Reporter: Michael Kurz With the artefacts for version 2.2.3 provided by Leo for the vote, I have severe problems with one of my applications. It seems, that there is some error showing a page with a template. First problem is, that a stylesheet linked in the template is not rendered. Therefore the page looks completely different in the browser. With 2.2.1 and 2.2.2 it works like expected. Additionally, two messages with the label Component with no name and no body content, so nothing rendered. are shown by h:messages. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] release of MyFaces Core 2.2.3
I created MYFACES-3882 including my application. Best regards Michi Am 12.04.2014 um 15:47 schrieb Leonardo Uribe lu4...@gmail.com: Hi We have only 6 changes in the release, and none of them are related to templates or resources. (3 for html friendly markup, 1 for the wrappers, 1 for the PostRestoreStateEvent, 1 for for attribute in a converter). Could you please give us more information about the specific example?. So I can run it and check by myself if something is wrong? regards, Leonardo Uribe On Apr 12, 2014 3:38 PM, Michael Kurz michi.k...@gmx.at wrote: -1 I have serious problems with version 2.2.3 provided by Leo and with the current snapshot in one of my examples. It seems, that there is some problem with resources or templates or both. The application works and looks fine with 2.2.1 and 2.2.2 but not with 2.2.3 or the current snapshot. Best regards Michi Am 11.04.2014 um 12:10 schrieb Werner Punz werner.p...@gmail.com: +1 Am 08.04.14 17:11, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.2.3 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1016/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces223binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326543
Re: [VOTE] release of MyFaces Core 2.2.2
+1 Am 18.03.2014 09:04, schrieb Thomas Andraschko: +1 2014-03-17 21:38 GMT+01:00 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com: +1 Am 17.03.14 08:05, schrieb Leonardo Uribe: +1 2014-03-17 2:05 GMT-05:00 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.2 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.2.2 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). --__-- [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. --__-- Thanks, Leonardo Uribe [1] https://repository.apache.org/__content/repositories/__orgapachemyfaces-1006/org/__apache/myfaces/ https://repository.apache.org/content/repositories/orgapachemyfaces-1006/org/apache/myfaces/ [2] http://www.apache.org/__foundation/voting.html#__ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~__lu4242/myfaces222binsrc http://people.apache.org/~lu4242/myfaces222binsrc [4] https://issues.apache.org/__jira/secure/ReleaseNote.jspa?__projectId=10600version=__12326474 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326474
[jira] [Commented] (MYFACES-3868) Passthrough element ignores passthrough attributes
[
https://issues.apache.org/jira/browse/MYFACES-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940892#comment-13940892
]
Michael Kurz commented on MYFACES-3868:
---
I opened the spec issue
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1270 for this.
Passthrough element ignores passthrough attributes
--
Key: MYFACES-3868
URL: https://issues.apache.org/jira/browse/MYFACES-3868
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.1
Reporter: Michael Kurz
Assignee: Leonardo Uribe
Attachments: MYFACES-3868-webapp-example.zip
In the following example, the passthrough element input has an attribute
placeholder, that should be added to the corresponding JSF component as a
passthrough attribute:
input type=text jsf:id=name jsf:value=#{bean.name}
placeholder=Enter name/
With MyFaces 2.2.1 however, the placeholder attribute is not rendered.
On further inspecting the component, I saw that placeholder is put in the
attributes map and not in the passthrough attributes map of the component.
That is probably the reason why it is not rendered.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3868) Passthrough element ignores passthrough attributes
Michael Kurz created MYFACES-3868:
-
Summary: Passthrough element ignores passthrough attributes
Key: MYFACES-3868
URL: https://issues.apache.org/jira/browse/MYFACES-3868
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.1
Reporter: Michael Kurz
In the following example, the passthrough element input has an attribute
placeholder, that should be added to the corresponding JSF component as a
passthrough attribute:
input type=text jsf:id=name jsf:value=#{bean.name}
placeholder=Enter name/
With MyFaces 2.2.1 however, the placeholder attribute is not rendered.
On further inspecting the component, I saw that placeholder is put in the
attributes map and not in the passthrough attributes map of the component. That
is probably the reason why it is not rendered.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3868) Passthrough element ignores passthrough attributes
[
https://issues.apache.org/jira/browse/MYFACES-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930460#comment-13930460
]
Michael Kurz commented on MYFACES-3868:
---
I checked the API doc of TagDecorator:
https://javaserverfaces.java.net/nonav/docs/2.2/javadocs/javax/faces/view/facelets/TagDecorator.html
There it is mentioned, that all tag attributes with an empty namespace or a
namespace different from the one of the element should be added as attribute to
the component. So the MyFaces behavior seems to be correct according to the
spec.
BUT: The text in the API documentation seems to be different from what Mojarra
implements as all attributes without a namespace seem to become passthrough
attributes in Mojarra (which perfectly makes sense for me and feels like the
natural behavior in this case).
So we probably have to verify if the spec text is correct here.
Passthrough element ignores passthrough attributes
--
Key: MYFACES-3868
URL: https://issues.apache.org/jira/browse/MYFACES-3868
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.1
Reporter: Michael Kurz
Attachments: MYFACES-3868-webapp-example.zip
In the following example, the passthrough element input has an attribute
placeholder, that should be added to the corresponding JSF component as a
passthrough attribute:
input type=text jsf:id=name jsf:value=#{bean.name}
placeholder=Enter name/
With MyFaces 2.2.1 however, the placeholder attribute is not rendered.
On further inspecting the component, I saw that placeholder is put in the
attributes map and not in the passthrough attributes map of the component.
That is probably the reason why it is not rendered.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3868) Passthrough element ignores passthrough attributes
[
https://issues.apache.org/jira/browse/MYFACES-3868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930857#comment-13930857
]
Michael Kurz commented on MYFACES-3868:
---
Good to hear that there is a simple workaround!
I will open a spec issue, as I think this should be clarified.
Passthrough element ignores passthrough attributes
--
Key: MYFACES-3868
URL: https://issues.apache.org/jira/browse/MYFACES-3868
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.1
Reporter: Michael Kurz
Attachments: MYFACES-3868-webapp-example.zip
In the following example, the passthrough element input has an attribute
placeholder, that should be added to the corresponding JSF component as a
passthrough attribute:
input type=text jsf:id=name jsf:value=#{bean.name}
placeholder=Enter name/
With MyFaces 2.2.1 however, the placeholder attribute is not rendered.
On further inspecting the component, I saw that placeholder is put in the
attributes map and not in the passthrough attributes map of the component.
That is probably the reason why it is not rendered.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3866) Unexpected result when using http://xmlns.jcp.org/jsf namespace
[
https://issues.apache.org/jira/browse/MYFACES-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925565#comment-13925565
]
Michael Kurz commented on MYFACES-3866:
---
The documentation for {{jsf:element}} specifies the component family and
renderer type:
https://javaserverfaces.java.net/nonav/docs/2.2/vdldocs/facelets/jsf/element.html
Unexpected result when using http://xmlns.jcp.org/jsf; namespace
-
Key: MYFACES-3866
URL: https://issues.apache.org/jira/browse/MYFACES-3866
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.0
Environment: Linux
Java 1.7
Tomcat 7
Reporter: Carl Moser
Assignee: Leonardo Uribe
Attachments: test-result.xhtml, test.xhtml
If I using the jsf:id element within a simple div, the rendered result is
something like this:
http://xmlns.jcp.org/jsf id=someDiv
p:elementName=div/http://xmlns.jcp.org/jsf
The following warning is shown.
Warning: The page /test.xhtml declares namespace null and uses the tag
http://xmlns.jcp.org/jsf , but no TagLibrary associated to namespace.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3866) Unexpected result when using http://xmlns.jcp.org/jsf namespace
[ https://issues.apache.org/jira/browse/MYFACES-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925296#comment-13925296 ] Michael Kurz commented on MYFACES-3866: --- In my opinion, the mentioned API spec for TextDecorator says, that the div element should become a component: If no matching entry is found, let jsf:element be the value of targetTag. This would mean, a component as specified in the description for jsf:element must be created. This totally makes sense for me, as this allows passthrough elements to be adressed by ajax JSF and to have f:ajax tags. Unexpected result when using http://xmlns.jcp.org/jsf; namespace - Key: MYFACES-3866 URL: https://issues.apache.org/jira/browse/MYFACES-3866 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.0 Environment: Linux Java 1.7 Tomcat 7 Reporter: Carl Moser Assignee: Leonardo Uribe Attachments: test-result.xhtml, test.xhtml If I using the jsf:id element within a simple div, the rendered result is something like this: http://xmlns.jcp.org/jsf id=someDiv p:elementName=div/http://xmlns.jcp.org/jsf The following warning is shown. Warning: The page /test.xhtml declares namespace null and uses the tag http://xmlns.jcp.org/jsf , but no TagLibrary associated to namespace. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] release of MyFaces Core 2.2.1
+1 Am 04.03.2014 um 06:41 schrieb Leonardo Uribe lu4...@gmail.com: +1 2014-03-04 0:40 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.1 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.2.1 [1] Keep in mind that this vote also include the new myfaces-impl-test module. The documentation of this feature can be found here: http://myfaces.staging.apache.org/wiki/core/user-guide/jsf-and-myfaces-howtos/unit-testing/setup-with-maven.html http://myfaces.staging.apache.org/wiki/core/user-guide/jsf-and-myfaces-howtos/unit-testing/create-test-junit-runner.html The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1005/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces221binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12325868
Re: [VOTE] release of MyFaces Core 2.2.0
+1 Am 09.01.2014 18:46, schrieb Grant Smith: +1 On Thu, Jan 9, 2014 at 9:07 AM, Paul Nicolucci pnico...@us.ibm.com mailto:pnico...@us.ibm.com wrote: +1 Regards, Paul Nicolucci Inactive hide details for Leonardo Uribe ---01/07/2014 11:00:23 PM---Hi, I was running the needed tasks to get the 2.2.0 releasLeonardo Uribe ---01/07/2014 11:00:23 PM---Hi, I was running the needed tasks to get the 2.2.0 release of Apache From: Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org mailto:dev@myfaces.apache.org, Date: 01/07/2014 11:00 PM Subject: [VOTE] release of MyFaces Core 2.2.0 Hi, I was running the needed tasks to get the 2.2.0 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.0 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-018/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces220binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316396 -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Updated] (MYFACES-3829) alwaysRecompile logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup
[ https://issues.apache.org/jira/browse/MYFACES-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3829: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed changes to trunk and JSF 2.1 branch. alwaysRecompile logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup Key: MYFACES-3829 URL: https://issues.apache.org/jira/browse/MYFACES-3829 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Affects Versions: 2.1.14-SNAPSHOT, 2.2.0 Reporter: Michael Kurz Fix For: 2.1.14, 2.2.0 Attachments: MYFACES-3829.patch The value alwaysRecompile introduced with MYFACES-3711 is logged as wrong value for the parameter org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup. This is, because it not configured as correct value in @JSFWebConfigParam. This applies only for 2.1 and 2.2 as alwaysRecompile is not available in 2.0 as far as have seen. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3829) alwaysRedirect logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup
Michael Kurz created MYFACES-3829: - Summary: alwaysRedirect logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup Key: MYFACES-3829 URL: https://issues.apache.org/jira/browse/MYFACES-3829 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Affects Versions: 2.1.14-SNAPSHOT, 2.2.0 Reporter: Michael Kurz The value alwaysRedirect introduced with MYFACES-3711 is logged as wrong value for the parameter org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup. This is, because it not configured as correct value in @JSFWebConfigParam. This applies only for 2.1 and 2.2 as alwaysRecompile is not available in 2.0 as far as have seen. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MYFACES-3829) alwaysRedirect logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup
[ https://issues.apache.org/jira/browse/MYFACES-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3829: -- Status: Patch Available (was: Open) alwaysRedirect logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup --- Key: MYFACES-3829 URL: https://issues.apache.org/jira/browse/MYFACES-3829 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Affects Versions: 2.1.14-SNAPSHOT, 2.2.0 Reporter: Michael Kurz Attachments: MYFACES-3829.patch The value alwaysRedirect introduced with MYFACES-3711 is logged as wrong value for the parameter org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup. This is, because it not configured as correct value in @JSFWebConfigParam. This applies only for 2.1 and 2.2 as alwaysRecompile is not available in 2.0 as far as have seen. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] release of MyFaces Core 2.2.0-beta
+1 Am 28.10.2013 15:59, schrieb Hazem Saleh: +1 On Mon, Oct 28, 2013 at 4:38 PM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: +1 Am 26.10.13 17:36, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.2.0-beta release of Apache MyFaces core out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.0 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.0-beta [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with the reference implementation. Please take a look at the 2.2.0-beta artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). --__-- [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. --__-- Thanks, Leonardo Uribe [1] https://repository.apache.org/__content/repositories/__orgapachemyfaces-034/org/__apache/myfaces/ https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/ [2] http://www.apache.org/__foundation/voting.html#__ReleaseVotes http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~__lu4242/myfaces220betabinsrc http://people.apache.org/~lu4242/myfaces220betabinsrc [4] https://issues.apache.org/__jira/secure/ReleaseNote.jspa?__projectId=10600version=__12325294 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12325294 -- Hazem Saleh Author of JavaScript Unit Testing book: http://www.amazon.com/dp/1782160620/ Co-author of (The Definitive Guide to Apache MyFaces and Facelets) book: http://www.amazon.com/-/e/B002M052KY DeveloperWorks Contributing Author https://www.ibm.com/developerworks/mydeveloperworks/blogs/hazem/entry/ibm_developerworks_contributing_author?lang=en_us An Apache committer, IBMer, and a technical speaker Twitter: http://www.twitter.com/hazems
[jira] [Updated] (MYFACES-3725) JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY
[ https://issues.apache.org/jira/browse/MYFACES-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3725: -- Resolution: Fixed Fix Version/s: 2.2.0 Status: Resolved (was: Patch Available) Functionality was added by someone else. JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY Key: MYFACES-3725 URL: https://issues.apache.org/jira/browse/MYFACES-3725 Project: MyFaces Core Issue Type: New Feature Components: JSR-344 Affects Versions: 2.2.0 Reporter: Michael Kurz Fix For: 2.2.0 Attachments: MYFACES-3725.patch The JSF 2.2 adds the new context parameter javax.faces.WEBAPP_RESOURCES_DIRECTORY to specify a custom resources directory that is used instead of /resources. The strange thing in the spec is, that the JavaDoc for ResourceHandler.WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME defines, that the specified value must not start with a '/'. This is also pointed out in JAVASERVERFACES_SPEC_PUBLIC-996 (see [1]) but unfortunately not answered. Even stranger as setting this parameter in a web app with Mojarra only works if it starts with '/'. [1]: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-996 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3677) Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY'
[ https://issues.apache.org/jira/browse/MYFACES-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670626#comment-13670626 ] Michael Kurz commented on MYFACES-3677: --- This issue can be closed, functionality is available in current snapshot version. Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY' -- Key: MYFACES-3677 URL: https://issues.apache.org/jira/browse/MYFACES-3677 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: dennis hoersch Attachments: MYFACES-3677-patch.txt Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY' as described in JSF 2.2 spec If this param is set, the runtime must interpret its value as a path, relative to the web app root, where resources are to be located. This param value must not start with a “/”, though it may contain “/” characters. If no such param exists, or its value is invalid, the value “resources”, without the quotes, must be used by the runtime as the value. I was looking last week for a way to move the 'resources' folder to a non-public location and read about this parameter. As I can't find if it is already implemented in 2.2 I gave it a try. I updated 'DefaultResourceHandlerSupport' to contain and use that parameter to instantiate the 'ExternalContextResourceLoader'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3725) JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY
Michael Kurz created MYFACES-3725: - Summary: JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY Key: MYFACES-3725 URL: https://issues.apache.org/jira/browse/MYFACES-3725 Project: MyFaces Core Issue Type: New Feature Reporter: Michael Kurz The JSF 2.2 adds the new context parameter javax.faces.WEBAPP_RESOURCES_DIRECTORY to specify a custom resources directory that is used instead of /resources. The strange thing in the spec is, that the JavaDoc for ResourceHandler.WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME defines, that the specified value must not start with a '/'. This is also pointed out in JAVASERVERFACES_SPEC_PUBLIC-996 (see [1]) but unfortunately not answered. Even stranger as setting this parameter in a web app with Mojarra only works if it starts with '/'. [1]: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-996 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3725) JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY
[ https://issues.apache.org/jira/browse/MYFACES-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3725: -- Status: Patch Available (was: Open) JSF 2.2: Custom webapp resources dir with javax.faces.WEBAPP_RESOURCES_DIRECTORY Key: MYFACES-3725 URL: https://issues.apache.org/jira/browse/MYFACES-3725 Project: MyFaces Core Issue Type: New Feature Reporter: Michael Kurz Attachments: MYFACES-3725.patch The JSF 2.2 adds the new context parameter javax.faces.WEBAPP_RESOURCES_DIRECTORY to specify a custom resources directory that is used instead of /resources. The strange thing in the spec is, that the JavaDoc for ResourceHandler.WEBAPP_RESOURCES_DIRECTORY_PARAM_NAME defines, that the specified value must not start with a '/'. This is also pointed out in JAVASERVERFACES_SPEC_PUBLIC-996 (see [1]) but unfortunately not answered. Even stranger as setting this parameter in a web app with Mojarra only works if it starts with '/'. [1]: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-996 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3723) JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE
Michael Kurz created MYFACES-3723: - Summary: JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE Key: MYFACES-3723 URL: https://issues.apache.org/jira/browse/MYFACES-3723 Project: MyFaces Core Issue Type: New Feature Components: JSR-344 Affects Versions: 2.2.0 Reporter: Michael Kurz The JSF 2.2 spec defines a new context parameter javax.faces.SERIALIZE_SERVER_STATE. This parameter controls state serialization for server side state saving. As far as I see it, it should be the same as the MyFaces parameter org.apache.myfaces.SERIALIZE_STATE_IN_SESSION. Maybe org.apache.myfaces.SERIALIZE_STATE_IN_SESSION can even be deprecated for 2.2? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3723) JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE
[ https://issues.apache.org/jira/browse/MYFACES-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3723: -- Status: Patch Available (was: Open) JSF 2.2: Support parameter javax.faces.SERIALIZE_SERVER_STATE - Key: MYFACES-3723 URL: https://issues.apache.org/jira/browse/MYFACES-3723 Project: MyFaces Core Issue Type: New Feature Components: JSR-344 Affects Versions: 2.2.0 Reporter: Michael Kurz The JSF 2.2 spec defines a new context parameter javax.faces.SERIALIZE_SERVER_STATE. This parameter controls state serialization for server side state saving. As far as I see it, it should be the same as the MyFaces parameter org.apache.myfaces.SERIALIZE_STATE_IN_SESSION. Maybe org.apache.myfaces.SERIALIZE_STATE_IN_SESSION can even be deprecated for 2.2? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-300) ViewParameterMode.INCLUDE incudes all request parameters
Michael Kurz created EXTCDI-300:
---
Summary: ViewParameterMode.INCLUDE incudes all request parameters
Key: EXTCDI-300
URL: https://issues.apache.org/jira/browse/EXTCDI-300
Project: MyFaces CODI
Issue Type: Bug
Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Michael Kurz
I have a view config with navigation set to REDIRECT and viewParams set to
INCLUDE like this:
@Page(navigation = Page.NavigationMode.REDIRECT,
viewParams = Page.ViewParameterMode.INCLUDE)
public class ShowProvider implements View {}
I use this view config as the result of an action method to navigate from an
edit page back to a details page with a redirect using the (single) view param
id for identifying the current item.
This works as expected, but additionally to the view param I get ALL request
parameters in the url. As this is a redirect from a POST that is quite a list
of parameters.
The parameters are added in
ViewConfigAwareNavigationHandler.convertEntryToOutcome() if
ViewParameterMode.INCLUDE is used on the view config - but I don't see why this
is done?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
MyFaces 2.2
Hi, are there any plans on starting a MyFaces Core 2.2 branch? I think Leo mentioned something a while ago. Regards Michi
[jira] [Commented] (MYFACES-3496) Unify myfaces archetypes and update to use jetty 8
[ https://issues.apache.org/jira/browse/MYFACES-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428173#comment-13428173 ] Michael Kurz commented on MYFACES-3496: --- Hi Leo, I just saw that you updated Jetty Maven Plugin 8 and ran into the tld scanning problem. I have the same problem for my tutorial examples that have profiles for MyFaces and Mojarra. I first also tried to load MyFaces/Mojarra as dependency in the plugin but it did not work out for me. MyFaces/Mojarra started fine but then I had problems with other jars (Bean Validation). So I guess this list of dependencies in the plugin might become longer and longer. However, I found a very simple solution. With the Jetty Maven Plugin you can specify an override web.xml enhancing the web apps web.xml like this: configuration webAppConfig overrideDescriptorsrc/main/jetty/override-myfaces-web.xml/overrideDescriptor /webAppConfig /configuration /plugin override-myfaces-web.xml looks like this: web-app ... listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener /web-app I simply have two of those override files for MyFaces and Mojarra that are defined as a property in the profile. Then the plugin can be defined in one place. Unify myfaces archetypes and update to use jetty 8 -- Key: MYFACES-3496 URL: https://issues.apache.org/jira/browse/MYFACES-3496 Project: MyFaces Core Issue Type: Improvement Components: Archetype Reporter: Leonardo Uribe Assignee: Leonardo Uribe Jetty 8 maven plugin is out and since people is using JSF2 / EL 2.2 / Servlet 3.0 , it could be good to use that plugin for all our JSF 2 archetypes. Also, I would like to contribute with a maven archetype I use frequently to debug myfaces stuff. It has some profile configurations that makes easier test myfaces in some situations, and also use some utilities used to create junit tests inside myfaces core. For example, it has a test case that checks if a xhtml can be recognized by facelets compiler. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Sick leave
Me too, I hope you get well soon. Michi Am 20.01.2012 19:25, schrieb Werner Punz: Thanks a lot guys, I am getting better already every day. I just had to give notice due to my role in the project, otherwise I probably would not even have written about it. I promise to be soon back in the saddle (in a few weeks) Werner Am 20.01.12 18:43, schrieb Leonardo Uribe: Hi Werner I hope you get well soon! regards, Leonardo 2012/1/20 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com Hey Werner, Sorry to hear that! I wish you a speedy recovery. Hope you get well soon! Regards, Jan-Kees Op 20 jan. 2012 16:15 schreef Matt Benson gudnabr...@gmail.com mailto:gudnabr...@gmail.com het volgende: Hi Werner, Sorry to hear that you are having health problems. I wish you a speedy recovery. Matt On Fri, Jan 20, 2012 at 2:26 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: I am currently on sick leave, which means, that I will be able to monitor the mailinglist about once per day, but bugfixes and implementation work will be postponed for a few weeks. The codebase for the jsf.js part is in an excellent state so it should be ok for 2-3 new releases and if something severe erupts in that part I will give consulting to whoever wants to tackle the task. The Ext-Scripting codebase has been now fixed up so that it works with the latest myfaces implementations, a new release will be pending as soon as I am out of the hospital. I will be back in the old state and working again for MyFaces in 2-3 weeks. Werner
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146166#comment-13146166 ] Michael Kurz commented on MYFACES-3382: --- @Ralf: The simplest solution is to add the following to the root pom.xml in the Myfaces sources. There already is a repository defined, just add it below: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://repository.apache.org/snapshots/url releases enabledfalse/enabled /releases /repository Hope this helps! Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142947#comment-13142947 ] Michael Kurz commented on MYFACES-3382: --- Do I see this correctly: After calling building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142947#comment-13142947 ] Michael Kurz edited comment on MYFACES-3382 at 11/3/11 8:26 AM: Do I see this correctly: After building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. was (Author: dr.gonzo): Do I see this correctly: After calling building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13143002#comment-13143002 ] Michael Kurz commented on MYFACES-3382: --- OK, I gave it another thought and I'm not so happy with the profile. What people see is: it does not work. Btw.: If the dependency to the parent can be resolved, we get the snapshot repository anyway via apache parent. So I would say no harm done if we add it again. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
MyFaces Parent 11-SNAPSHOT
HI guys, I just saw that some days ago the version of the parent pom in myfaces-core was changed to 11-SNAPSHOT. I had no problems with this as I had the dependency in my repo. But we just had problems on a 'clean' machine. Maven could not find the dependency. So I guess the solution would be: a) Add the snapshot repository to myfaces-parent. b) Revert to version 10 of the parent. I fixed something like this some weeks ago for snapshot plugins. So if someone can confirm this I can make the according change. regards Michael
Re: MyFaces Parent 11-SNAPSHOT
Hi Leo, I mixed up the artifacts. We should add the snapshot repository to the pom file of myfaces-core to fix the build. If we add it to the parent, a snapshot parent won't be found. But maybe we talk about the same anyway ;) regards Michael Am 02.11.2011 um 17:40 schrieb Leonardo Uribe lu4...@gmail.com: Hi Michael It is better to do a) Add the snapshot repository to myfaces-parent. I hope to send a vote to release myfaces master pom and myfaces checkstyle rules soon, to fix the problem, but it will take some days before publish the artifacts on the repo. regards, Leonardo Uribe 2011/11/2 Michael Kurz michi.k...@gmx.at: HI guys, I just saw that some days ago the version of the parent pom in myfaces-core was changed to 11-SNAPSHOT. I had no problems with this as I had the dependency in my repo. But we just had problems on a 'clean' machine. Maven could not find the dependency. So I guess the solution would be: a) Add the snapshot repository to myfaces-parent. b) Revert to version 10 of the parent. I fixed something like this some weeks ago for snapshot plugins. So if someone can confirm this I can make the according change. regards Michael
Re: MyFaces Parent 11-SNAPSHOT
But if Maven can't resolve the myfaces-parent (as it is a snapshot) it won't find apache-parent either. regards Michael Am 02.11.2011 um 20:13 schrieb Mark Struberg strub...@yahoo.de: any apache snapshots will get deployed to apache.snapshots which should be configured in apache-parent. Thus we don't need to add it ourselfs. LieGrue, strub - Original Message - From: Michael Kurz michi.k...@gmx.at To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Wednesday, November 2, 2011 8:01 PM Subject: Re: MyFaces Parent 11-SNAPSHOT Hi Leo, I mixed up the artifacts. We should add the snapshot repository to the pom file of myfaces-core to fix the build. If we add it to the parent, a snapshot parent won't be found. But maybe we talk about the same anyway ;) regards Michael Am 02.11.2011 um 17:40 schrieb Leonardo Uribe lu4...@gmail.com: Hi Michael It is better to do a) Add the snapshot repository to myfaces-parent. I hope to send a vote to release myfaces master pom and myfaces checkstyle rules soon, to fix the problem, but it will take some days before publish the artifacts on the repo. regards, Leonardo Uribe 2011/11/2 Michael Kurz michi.k...@gmx.at: HI guys, I just saw that some days ago the version of the parent pom in myfaces-core was changed to 11-SNAPSHOT. I had no problems with this as I had the dependency in my repo. But we just had problems on a 'clean' machine. Maven could not find the dependency. So I guess the solution would be: a) Add the snapshot repository to myfaces-parent. b) Revert to version 10 of the parent. I fixed something like this some weeks ago for snapshot plugins. So if someone can confirm this I can make the according change. regards Michael
Re: [VOTE] extend maximum allowed line length from 120 to 160
Hi Mark, I can help you on this one - but probably not before Monday or Tuesday. Btw.: Do you already have a settings file for IntelliJ 10.5? regards Michael Am 28.10.2011 20:49, schrieb Mark Struberg: As I said earlier, the 160 char/line proposal was just made because I'm pretty tired of fixing the checkstyle issues in myfaces-core already. If anyone is up for taking that piece of cake, then I'd be happy. Otherwise I will do it over the weekend. LieGrue, strub From: Blake Sullivanblake.sulli...@oracle.com To: MyFaces Developmentdev@myfaces.apache.org Cc: Gerhard Petracekgerhard.petra...@gmail.com Sent: Friday, October 28, 2011 8:13 PM Subject: Re: [VOTE] extend maximum allowed line length from 120 to 160 I personally find 120 characters to be the best balance. On the bright side, I expect that once we can use the diamond operator in JDK 7, the pressure for longer lines will decrease. -- Blake Sullivan On 10/28/11 10:33 AM, Gerhard Petracek wrote: @80: -1! @rest: +0 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/28 Volker Weberv.we...@inexso.de Hi Mark, 2011/10/28 Mark Strubergstrub...@yahoo.de: Volker, source code is no newspaper. just wanted to support the statement of easier reading in smaller columns, of cause code is no newspaper, but it still need easy reading. I don't like to scroll left and right to read the code, and even at work were i got the widest screen the 1920px did not suffice to see more than 120 characters with the project and structure sidebars left and right, which i would not like to miss. Regards, Volker Imo 80 chars is definitely fine for C or perl with cryptic syntax (programmed that myself for 20 years) but it's not nice for languages where descriptive variable and method names are 'socially accepted' ;) LieGrue, strub - Original Message - From: Volker Weberv.we...@inexso.de To: MyFaces Developmentdev@myfaces.apache.org; Mark Strubergstrub...@yahoo.de Cc: Sent: Friday, October 28, 2011 9:22 AM Subject: Re: [VOTE] extend maximum allowed line length from 120 to 160 Hi, -1. In my opinion 160 characters is much to wide, the current 120 is not the preferred, but the allowed max width. I vote for 80 characters as preferred max width. In general reading is easier if the text is not too wide, thats why newspaper articles are layouted in columns. Regards, Volker 2011/10/26 Mark Strubergstrub...@yahoo.de: Hi! Currently we have really long and very descriptive variable names in MyFaces. I personally like that, but due to that we are really often exceeding the 120 character per line. Thus my question: should we extend this from 120 to 160 characters being allowed per line? [+1] yup make 160 the max default [0] don't care [-1] nope, let's stick with 120 open for 72h ... Please make use of your vote, because I will activate the checkstyle checks soon ;) here is my +1. LieGrue, strub -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
Re: [VOTE] extend maximum allowed line length from 120 to 160
-1 Am 26.10.2011 14:18, schrieb Mark Struberg: Hi! Currently we have really long and very descriptive variable names in MyFaces. I personally like that, but due to that we are really often exceeding the 120 character per line. Thus my question: should we extend this from 120 to 160 characters being allowed per line? [+1] yup make 160 the max default [0] don't care [-1] nope, let's stick with 120 open for 72h ... Please make use of your vote, because I will activate the checkstyle checks soon ;) here is my +1. LieGrue, strub
Re: treating obsolete code
+1 Am 26.10.2011 18:20, schrieb Mike Kienenberger: +1 since you can always get it back out of svn if you need it. On Wed, Oct 26, 2011 at 12:08 PM, Mark Strubergstrub...@yahoo.de wrote: Hi folks! I see a lot of commented out code which is many years old. I'm highly in favour to just delete code we don't need anymore! IF you only temporarily comment out something, then please mark it with /*X TODO some comment or //X TODO some comment otherwise comments must ONLY be used for one thing - commenting the code! LieGrue, strub
Re: java.lang.IllegalStateException: zip file closed
Hi, have you already tried it on another servlet container like tomcat? I guess the key for finding out what happens is the other thread that does not fail. The first thing I would try to find out is where the JarFileResource (or the underlying file) is closed. Have you checked that the resource in question is really loaded with the code that was changed with the Jetty patch? regards Michael Am 25.10.2011 um 14:47 schrieb gregor.jari...@raibau.at: Hello, we are developing internal software based on myfaces (2.0.2) and jetty (7.1.6). We ran into the following problem: After the start of the server, if two requests (threads) are send at the same time, jetty reports an IllegalStateException: zip file closed. To me it seems that one request is closing the stream when it has finished using it, so for the second request it has already been closed when it trys to attempt using it. After some research we had a very promising solution suggestion: http://jira.codehaus.org/browse/JETTY-254 http://jira.codehaus.org/secure/attachment/26212/JETTY-254-2.patch We did patch it, but the behaviour did not change at all. It also doesn't work with the current jetty (in which the patch is also included). Following is our stacetrace; It is very similar to the problem described in the jira issue above. Still, it seems to be something else. I am glad for any suggestions. Thanks in advance. java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:403) ~[na:1.6.0_17] at java.util.zip.ZipFile.access$100(ZipFile.java:29) ~[na:1.6.0_17] at java.util.zip.ZipFile$2.nextElement(ZipFile.java:309) ~[na:1.6.0_17] at java.util.zip.ZipFile$2.nextElement(ZipFile.java:299) ~[na:1.6.0_17] at java.util.jar.JarFile$1.nextElement(JarFile.java:223) ~[na:1.6.0_17] at java.util.jar.JarFile$1.nextElement(JarFile.java:218) ~[na:1.6.0_17] at org.eclipse.jetty.util.resource.JarFileResource.exists(JarFileResource.java:163) ~[org.eclipse.jetty.util_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.webapp.WebAppContext.getResource(WebAppContext.java:290) ~[org.eclipse.jetty.webapp_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1003) ~[org.eclipse.jetty.webapp_7.1.6.v20100715.jar:7.1.6.v20100715] at org.apache.myfaces.context.servlet.ServletExternalContextImplBase.getResource(ServletExternalContextImplBase.java:121) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.shared_impl.resource.ExternalContextResourceLoader.getResourceURL(ExternalContextResourceLoader.java:144) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.application.ResourceHandlerImpl.deriveResourceMeta(ResourceHandlerImpl.java:228) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:104) ~[myfaces-impl-2.0.2.jar:2.0.2] at javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:50) ~[myfaces-api-2.0.2.jar:2.0.2] at org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:82) ~[tomahawk20-1.1.10.jar:1.1.10] at org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:107) ~[tomahawk20-1.1.10.jar:1.1.10] at javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:50) ~[myfaces-api-2.0.2.jar:2.0.2] at org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:82) ~[tomahawk20-1.1.10.jar:1.1.10] at org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:107) ~[tomahawk20-1.1.10.jar:1.1.10] at org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61) ~[tomahawk20-1.1.10.jar:1.1.10] at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.containsTagHandler(TagLibraryConfig.java:97) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.view.facelets.tag.CompositeTagLibrary.containsTagHandler(CompositeTagLibrary.java:73) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.view.facelets.compiler.CompilationManager.pushTag(CompilationManager.java:270) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.myfaces.view.facelets.compiler.SAXCompiler$CompilationHandler.startElement(SAXCompiler.java:227) ~[myfaces-impl-2.0.2.jar:2.0.2] at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133963#comment-13133963 ] Michael Kurz commented on MYFACES-3368: --- Btw.: Is [1] really the only and definite source for MyFaces code style? I recently had a look at the guidelines and then at some MyFaces code. There was not much compliance especially regarding new lines before and after braces and stuff like that. Maybe we should clarify this and update the wiki accordingly (unless I missed the 'true' source). [1]: https://cwiki.apache.org/MYFACES/myfaces-developer-notes.html enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Mark Struberg We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3368) enable 'standard' checkstyle checks in myfaces-core
[ https://issues.apache.org/jira/browse/MYFACES-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133973#comment-13133973 ] Michael Kurz commented on MYFACES-3368: --- Yes, it didn't work for me too on IDEA 10.5. enable 'standard' checkstyle checks in myfaces-core --- Key: MYFACES-3368 URL: https://issues.apache.org/jira/browse/MYFACES-3368 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.3 Reporter: Mark Struberg Assignee: Mark Struberg We currently only have the 'minimal' checks enabled in core, which actually only checks the correct license headers. We should go for the 'standard' checkstyle rules, even if this would take some time to fix (found errors only in the first module). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3370) f:selectItem ignores rendered attribute
[
https://issues.apache.org/jira/browse/MYFACES-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13134114#comment-13134114
]
Michael Kurz commented on MYFACES-3370:
---
This issue is not valid and should be closed as f:selectItems does not define a
rendered attribute (see [1]). The attribute rendered is only available for
components.
If you want to build dynamic select item lists, you can use f:selectItems with
a property of type ListSelectItem in the value attribute.
[1]: http://javaserverfaces.java.net/nonav/docs/2.1/
f:selectItem ignores rendered attribute
---
Key: MYFACES-3370
URL: https://issues.apache.org/jira/browse/MYFACES-3370
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.9
Environment: Jetty 6, Myfaces 2.0.9, Primefaces 3.0
Reporter: Joe Rossi
Priority: Minor
In the following snippet:
h:selectOneMenu id=selector
value=#{cc.attrs.backingBean[cc.attrs.property]}
required=#{cc.attrs.required}
requiredMessage=#{cc.attrs.requiredMessage}
disabledClass=tnui-selectDisabled
disabled=#{cc.attrs.disabled}
immediate=#{cc.attrs.immediate}
readonly=#{cc.attrs.readonly}
onchange=#{cc.attrs.onchange}
style=#{cc.attrs.style}
f:selectItem
itemLabel=#{cc.attrs.noSelectOptionLabel}#{sessionBean.classOfService}
itemValue=#{null}
noSelectionOption=true
rendered=false/
p:ajax update=#{cc.attrs.updateTargets}
disabled=#{!includeAjaxUpdate}/
composite:insertChildren /
/h:selectOneMenu
The embedded f:selectItem is always included even though it's rendered
attribute is set to false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3370) f:selectItem ignores rendered attribute
[
https://issues.apache.org/jira/browse/MYFACES-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13134168#comment-13134168
]
Michael Kurz commented on MYFACES-3370:
---
No problem! I just wanted to clarify this. If you have further questions feel
free to post them on us...@myfaces.apache.org.
f:selectItem ignores rendered attribute
---
Key: MYFACES-3370
URL: https://issues.apache.org/jira/browse/MYFACES-3370
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.9
Environment: Jetty 6, Myfaces 2.0.9, Primefaces 3.0
Reporter: Joe Rossi
Priority: Minor
In the following snippet:
h:selectOneMenu id=selector
value=#{cc.attrs.backingBean[cc.attrs.property]}
required=#{cc.attrs.required}
requiredMessage=#{cc.attrs.requiredMessage}
disabledClass=tnui-selectDisabled
disabled=#{cc.attrs.disabled}
immediate=#{cc.attrs.immediate}
readonly=#{cc.attrs.readonly}
onchange=#{cc.attrs.onchange}
style=#{cc.attrs.style}
f:selectItem
itemLabel=#{cc.attrs.noSelectOptionLabel}#{sessionBean.classOfService}
itemValue=#{null}
noSelectionOption=true
rendered=false/
p:ajax update=#{cc.attrs.updateTargets}
disabled=#{!includeAjaxUpdate}/
composite:insertChildren /
/h:selectOneMenu
The embedded f:selectItem is always included even though it's rendered
attribute is set to false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] release CODI-1.0.2?
I'm using 1.0.2-SNAPSHOT and it works fine for me. So go for it! regards Michael Am 17.10.2011 um 19:00 schrieb Gerhard Petracek gerhard.petra...@gmail.com: hi mark, we have to document the new features, we need a final review,... afterwards we can start with the release. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/17 Jakob Korherr jakob.korh...@gmail.com +1 Regards, Jakob 2011/10/17 Mark Struberg strub...@yahoo.de: Hi folks! We've done some fairly big improvements and new features since the release of CODI-1.0.2. So I think it's time to release CODI-1.0.2. For the release notes, please see [1]. The only issue which blocks us atm is the relase of MyFaces-parent-10. Leo, can we release the checkstyle-rules and myfaces-parent already? I've tested it with myfaces-core locally, should I commit the upgrade? Wdyt? LieGrue, strub [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311071version=12317614 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Snapshot of myfaces-builder-plugin in pom.xml
Hi, since yesterday, the dependencies to myfaces-builder-plugin and myfaces-builder-annotations have the latest snapshot version. This breaks the build for me as Maven is not able to resolve these dependencies. The problem seems to be, that the snapshot repository [1] is not added as plugin repository. When I add a pluginRepository to the myfaces core it works again. If this is the way to go (and the repo should not be referenced somewhere else) I will create an issue and provide a patch. Best regards Michael [1] https://repository.apache.org/snapshots/org/apache/myfaces/buildtools/myfaces-builder-plugin/1.0.10-SNAPSHOT/
[jira] [Created] (MYFACES-3349) Plugin snapshot repository missing in MyFaces core pom.xml
Plugin snapshot repository missing in MyFaces core pom.xml -- Key: MYFACES-3349 URL: https://issues.apache.org/jira/browse/MYFACES-3349 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.4-SNAPSHOT Reporter: Michael Kurz MyFaces Core pom.xml references myfaces-builder-plugin and myfaces-builder-annotations in snapshot versions but the snapshot repository is not configures as plugin repository. Therefore the build is broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3349) Plugin snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz resolved MYFACES-3349. --- Resolution: Fixed Fix Version/s: 2.1.4-SNAPSHOT Committed changes in pom.xml. Plugin snapshot repository missing in MyFaces core pom.xml -- Key: MYFACES-3349 URL: https://issues.apache.org/jira/browse/MYFACES-3349 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.4-SNAPSHOT Reporter: Michael Kurz Fix For: 2.1.4-SNAPSHOT MyFaces Core pom.xml references myfaces-builder-plugin and myfaces-builder-annotations in snapshot versions but the snapshot repository is not configures as plugin repository. Therefore the build is broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Snapshot of myfaces-builder-plugin in pom.xml
It is fixed. Am 07.10.2011 16:32, schrieb Leonardo Uribe: Hi Yes, it is the way to go. Sometimes it is necessary to build against a snapshot. Please add the changes. Regards, Leonardo Am 07.10.2011 09:16 schrieb Michael Kurz michi.k...@gmx.at mailto:michi.k...@gmx.at: Hi, since yesterday, the dependencies to myfaces-builder-plugin and myfaces-builder-annotations have the latest snapshot version. This breaks the build for me as Maven is not able to resolve these dependencies. The problem seems to be, that the snapshot repository [1] is not added as plugin repository. When I add a pluginRepository to the myfaces core it works again. If this is the way to go (and the repo should not be referenced somewhere else) I will create an issue and provide a patch. Best regards Michael [1] https://repository.apache.org/__snapshots/org/apache/myfaces/__buildtools/myfaces-builder-__plugin/1.0.10-SNAPSHOT/ https://repository.apache.org/snapshots/org/apache/myfaces/buildtools/myfaces-builder-plugin/1.0.10-SNAPSHOT/
[jira] [Commented] (MYFACES-3313) Calculation of redirect URL does not preserve the extension used in Faces Servlet mapping
[
https://issues.apache.org/jira/browse/MYFACES-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121891#comment-13121891
]
Michael Kurz commented on MYFACES-3313:
---
I would say this is not a MyFaces bug. The problem here is, that you use
/page01.jsf and /page02.jsf in to-view-id. But those values are NOT the view
IDs of your views but the mapped url in the browser. The view IDs are
/page01.xhtml and /page02.xhtml.
IMO, this issue can be closed as invalid.
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
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.2, 2.1.3
Reporter: Deryk Sinotte
I have a simple navigation test case that does a navigation between two
pages. Both pages have the same simple markup:
h:body
h2Page 01/h2
h:form
h:commandButton id=navButton
value=Nav
action=#{testBean.lastPage} /
/h:form
/h:body
The backing bean methods simply return the appropriate action outcome:
public String lastPage(){
return lastPage;
}
And the faces-config file has the following navigation rules:
navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomelastPage/from-outcome
to-view-id/page02.jsf/to-view-id
redirect/
/navigation-case
navigation-case
from-outcomefirstPage/from-outcome
to-view-id/page01.jsf/to-view-id
redirect/
/navigation-case
/navigation-rule
The web.xml has a servlet mapping for .jsf files:
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.jsf/url-pattern
/servlet-mapping
If I go to the page01.jsf, the page loads fine. When I click the Nav
button, the navigation occurs but the URL is page02.xhtml rather than
page02.jsf. Because the extension is not preserved and there is no mapping
for .xhtml in this case, the page doesn't get handled by the Faces Servlet.
The current version of Mojarra (2.1.3) does preserve the extension when the
redirect URL is encoded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3304) NullPointerException using h:selectOneRadio with an enum
[
https://issues.apache.org/jira/browse/MYFACES-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121945#comment-13121945
]
Michael Kurz commented on MYFACES-3304:
---
A shot in the dark: I would say this does not work because the following two
lines don't work as expected:
f:selectItem itemValue=#{VALUEA} itemLabel=labelA/
f:selectItem itemValue=#{VALUEB} itemLabel=labelB/
Unless you have a special ELResolver that resolves VALUEA and VALUEB (which I
guess you don't have) the values will resolve to null. You should create
SelectItem instances in the managed bean (preferred) or create a property on
the bean for each enum constants.
Nevertheless, there should not be a NPE in HtmlRadioRendererBase.java:221. The
problem is, that EnumConverter returns null in this case for itemStrValue.
Easiest solution would be to set itemStrValue to if it is null.
Any objections? Leo?
NullPointerException using h:selectOneRadio with an enum
Key: MYFACES-3304
URL: https://issues.apache.org/jira/browse/MYFACES-3304
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.8
Environment: Ubuntu 11.0.4, Jetty 6.1.10, JDK 1.6, Myfaces Core
2.0.8, Primefaces 3.0.M3
Reporter: Joe Rossi
Priority: Minor
Trying to use a h:selectOneRadio to select one of two values for an enum and
it fails, throwing a NullPointerException. No explicit converter is in use so
(from debugging) it appears to be using the default EnumConverter.
Code snippets in question are as follows:
testLovs.xhtml:
h:panelGrid columns=1
Simple radio button with constant string values
h:selectOneRadio id=l1 value=#{testLovsBean.l1}
f:selectItem itemValue=A itemLabel=labelA/
f:selectItem itemValue=B itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l1Str value=l1: #{testLovBean.l1AsString}/
p:separator/
Radio button for enum
h:selectOneRadio id=l2 value=#{testLovsBean.l2}
f:selectItem itemValue=#{VALUEA} itemLabel=labelA/
f:selectItem itemValue=#{VALUEB} itemLabel=labelB/
/h:selectOneRadio
h:outputText id=l2Str value=l2: #{testLovBean.l2AsString}/
p:separator/
p:commandButton id=commitCommand
action=#{testLovsBean.commitAction}
value=Submit
ajax=false/
TestLovsBean.java:
package tn.view.bean.test;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import tn.view.util.FacesUtils;
/**
* Class used for testing date controls
*/
@Component
@Scope(request)
public class TestLovsBean
{
public TestLovsBean()
{
}
public String getL1()
{
return _l1;
}
public void setL1(String l1)
{
_l1 = l1;
}
public String getL1AsString()
{
return _l1;
}
public TestEnum getL2()
{
return _l2;
}
public void setL2(TestEnum l2)
{
_l2 = l2;
}
public String commitAction()
{
System.out.println(commitAction invoked);
FacesUtils.addInfoMessage(L1: + _l1);
FacesUtils.addInfoMessage(L2: + _l2);
return null;
}
private String _l1;
private TestEnum _l2;
}
TestEnum.java:
package tn.view.bean.test;
public enum TestEnum
{
VALUEA,
VALUEB,
}
Stack trace:
javax.servlet.ServletException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:221)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
tn.view.error.ResponseCapturingFilter.doFilter(ResponseCapturingFilter.java:83)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
tn.view.error.AbstractUncaughtExceptionInterceptor.doFilter(AbstractUncaughtExceptionInterceptor.java:66)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:292)
at
net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:108)
at
net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter(SecurityEnforcementFilter.java:197)
at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
at
net.sf.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:143)
at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
at
net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter
Re: [COMMUNITY] MyFaces += Michael Kurz
Thank you very much! Best regards Michi Am 30.09.2011 um 17:53 schrieb Leonardo Uribe lu4...@gmail.com: Welcome Michael! 2011/9/30 Grant Smith work.gr...@gmail.com: Welcome, Michael. On Fri, Sep 30, 2011 at 8:22 AM, Matt Benson gudnabr...@gmail.com wrote: +1: Congratulations, Michael. Matt On Fri, Sep 30, 2011 at 4:48 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Michael, Congrats! Regards, Jakob 2011/9/30 Martin Marinschek mmarinsc...@apache.org: Hi Michael, congratulations! best regards, Martin On Fri, Sep 30, 2011 at 9:09 AM, Werner Punz werner.p...@gmail.com wrote: Am 9/30/11 8:11 AM, schrieb Gerhard Petracek: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Michael Kurz as the newest MyFaces committer! Michael is an active member of the MyFaces community, especially in MyFaces Core. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard Congratulations Michael, well deserved. werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- 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.
[jira] [Commented] (MYFACES-3326) UIData does not preserve submitted values on immediate requests
[ https://issues.apache.org/jira/browse/MYFACES-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13115270#comment-13115270 ] Michael Kurz commented on MYFACES-3326: --- I did some further investigations and the problem is the same in Mojarra. The spec doc for UIData.encodeBegin() says the following: In addition to the default behavior, ensure that any saved per-row state for our child input components is discarded unless it is needed to rerender the current page with errors. I additionaly scanned the spec and found no mention of displaying the submitted value if it is still set in render response (which apparently is done). So what do you think: Is this a valid issue? UIData does not preserve submitted values on immediate requests --- Key: MYFACES-3326 URL: https://issues.apache.org/jira/browse/MYFACES-3326 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz Attachments: MYFACES-3326-testapp.zip I have a h:dataTable component with an h:inputText component per row bound to a list. Now I want to add a new row with a h:commandLink outside the table via ajax. This link is immediate to avoid validation on the input components. The problem is, that when I set the command link immediate, data the user entered into the input components vanishes (render and execute in f:ajax are set to the table). I did some investigations and saw that UIData.encodeBegin() resets the state (and submitted values!) before rendering. IMO, the submitted values must be preserved if phases 3 to 5 are skipped. I first thought that setting _isValidChilds to false in processDecodes if renderResponse() is called might work. But as the link is outside and after the table renderResponse() is not called yet at that point. I wonder what the correct way to handle this could be? Maybe remember if processValidators() was called on the table. If not, don't kill the state. Btw. the same applies for ui:repeat. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-229) Optional SecurityViolationHandler
Optional SecurityViolationHandler - Key: EXTCDI-229 URL: https://issues.apache.org/jira/browse/EXTCDI-229 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF20-Module Affects Versions: 1.0.1 Reporter: Michael Kurz I use @Secured with a custom AccessDecisionVoter checking if a user is logged in. If the user is not logged in I only want to redirect to the login page. Currently it is not possible to do this without creating a message in the FacesContext. As discussed with Gerhard, a simple solution for this would be an optional SecurityViolationHandler. If there is a bean for this type, it is used to handle SecurityViolation instances created in the voter. If not, the default behavior (adding messages to the facesContext) should be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Discussion on MYFACES-3326
Hi, I would like to move the discussion about MYFACES-3326 ([1]) from the issue over her (as suggested by Mike). I don't want to repeat the whole story, but I am very interested if this is a bug (probably not as Mojarra behaves the same way), if it is underspecified or if I wrongly assumed that this should work like I expected. Best regards Michael [1]: https://issues.apache.org/jira/browse/MYFACES-3326
Re: Discussion on MYFACES-3326
Hi Leo, a first idea would be to remember if validation was executed at all. If not, the state should be kept. I added a simple patch for this to the issue (it works for me but there might be side effects I'm not aware of). Am 27.09.2011 um 16:23 schrieb Leonardo Uribe: Hi Some weeks ago, I read the description of UIData.encodeBegin() too. That description comes from JSF 1.0, so in that time it had sense, but with JSF 2.0 we have new use cases and that description is becoming problematic. For example, originally the idea was that if a conversion/validation error occur, an error message is added so the model/state must be preserved. In JSF 2.0 we have FacesContext.isValidationFailed() method, so one idea is check this condition in that part, but still it seems to be insuficient. I suppose a change on the spec should be done in that part, but I still don't get how it should looks like. There are some cases like the one described on MYFACES-3326 that requires something special, to indicate the model/state should not be cleared. For now the only workaround is create a copy and implement UIData class and add some code there, just like in tomahawk, but that does not solve the problem on the spec. Suggestions are welcome. regards, Leonardo Uribe 2011/9/27 Michael Kurz michi.k...@gmx.at Hi, I would like to move the discussion about MYFACES-3326 ([1]) from the issue over her (as suggested by Mike). I don't want to repeat the whole story, but I am very interested if this is a bug (probably not as Mojarra behaves the same way), if it is underspecified or if I wrongly assumed that this should work like I expected. Best regards Michael [1]: https://issues.apache.org/jira/browse/MYFACES-3326
[jira] [Created] (MYFACES-3319) Make create AjaxBehavior accessible in AjaxHandler
Make create AjaxBehavior accessible in AjaxHandler -- Key: MYFACES-3319 URL: https://issues.apache.org/jira/browse/MYFACES-3319 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz Priority: Minor I'm currently trying to create a custom ajax tag that is based on f:ajax but supports an additional attribute. For this, I wanted to create a new tag handler that extends AjaxHandler. What I found out is, that it is VERY hard to do so. The creation of the AjaxBehavior is buried inside applyAttachedObject(). The only reasonable way I found to set an additional value expression on the created AjaxBehavior is to pass in a wrapped FacesContext/Application from the derived class. It would be so much easier, if, for instance, creating the behavior would be done in a protected method. Then the behavior would be accessible in derived classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3319) Make create AjaxBehavior accessible in AjaxHandler
[ https://issues.apache.org/jira/browse/MYFACES-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3319: -- Status: Patch Available (was: Open) Make create AjaxBehavior accessible in AjaxHandler -- Key: MYFACES-3319 URL: https://issues.apache.org/jira/browse/MYFACES-3319 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz Priority: Minor Attachments: MYFACES-3319.patch I'm currently trying to create a custom ajax tag that is based on f:ajax but supports an additional attribute. For this, I wanted to create a new tag handler that extends AjaxHandler. What I found out is, that it is VERY hard to do so. The creation of the AjaxBehavior is buried inside applyAttachedObject(). The only reasonable way I found to set an additional value expression on the created AjaxBehavior is to pass in a wrapped FacesContext/Application from the derived class. It would be so much easier, if, for instance, creating the behavior would be done in a protected method. Then the behavior would be accessible in derived classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3320) Ajax problem with Webkit based browsers on MacOS
Ajax problem with Webkit based browsers on MacOS Key: MYFACES-3320 URL: https://issues.apache.org/jira/browse/MYFACES-3320 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.4-SNAPSHOT Environment: Safari 5.1 and Chrome 14.0.835.186 on MacOS 10.7.1 Reporter: Michael Kurz Priority: Blocker In 2.1.4-SNAPSHOT there seems to be a serious problem with Ajax on Webkit based browsers. I have a table that is updated via a ajax call that adds a row to this table. In Safari and Chrome (MacOS) this works only once (then no further requests are issued). This problem does not occur with Firefox. Neither do I have troubles like this with version 2.1.3 on any browser. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
and
Courses in English and German
Professional Support for Apache MyFaces
2011/9/21 Rudy De Busscherrdebussc...@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.gr...@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.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
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
-
From: Matt
Bensongudnabr...@gmail.com
To: MyFaces
Developmentdev@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.petra...@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
Busscherrdebussc...@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.gr...@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.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
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] [Created] (MYFACES-3314) AjaxBehavior.getStateHelper() should be protected
AjaxBehavior.getStateHelper() should be protected - Key: MYFACES-3314 URL: https://issues.apache.org/jira/browse/MYFACES-3314 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz I just tried to create a new custom AjaxBehavior. I extended MyFaces' AjaxBehavior and saw that both getStateHelper() methods are private, which makes it kind of hard. They should be protected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3314) AjaxBehavior.getStateHelper() should be protected
[ https://issues.apache.org/jira/browse/MYFACES-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3314: -- Status: Patch Available (was: Open) AjaxBehavior.getStateHelper() should be protected - Key: MYFACES-3314 URL: https://issues.apache.org/jira/browse/MYFACES-3314 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz Attachments: MYFACES-3314.patch I just tried to create a new custom AjaxBehavior. I extended MyFaces' AjaxBehavior and saw that both getStateHelper() methods are private, which makes it kind of hard. They should be protected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+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 michi.k...@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 Kurzmichi.k...@gmx.at To: MyFaces Developmentdev@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 Marinschekmmarinsc...@apache.org: +1 in general, +1 to Bernd's suggestion. best regards, Martin On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @bernd: +1 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/22 Bernd Bohmannbernd.bohm...@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 Strubergstrub...@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 - From: Jakob Korherrjakob.korh...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org Cc: gudnabr...@gmail.com Sent: Wednesday, September 21, 2011 10:20 PM Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 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 Uribelu4...@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 Uribelu4...@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
[jira] [Created] (MYFACES-3315) @FacesValidator.isDefault() not processed
@FacesValidator.isDefault() not processed - Key: MYFACES-3315 URL: https://issues.apache.org/jira/browse/MYFACES-3315 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz Priority: Minor It is not possible to add a default validator with @FacesValidator(value=someID, isDefault = true). I had to add the validator id manually in the faces-config.xml to make it work. It looks like the isValid() element is not processed in AnnotationConfigurator. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-2552) TagValueExpression.getType() returns null if the property in the managed bean is null and the expression points to a facelets composite component attribute
[
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. What is the status on this?
For what I see, it will be fixed in JSF 2.2 (see [1]). But shouldn't this be
fixed for older versions too?
[1]: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745
TagValueExpression.getType() returns null if the property in the managed bean
is null and the expression points to a facelets composite component attribute
---
Key: MYFACES-2552
URL: https://issues.apache.org/jira/browse/MYFACES-2552
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.0
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2552-spec-proposal.patch
if you have a facelets composite component with an attribute test that
points to a property in a managed bean (e.g. #{myBean.property}) which is
currently null and you refer to that attribute in the implementation via
#{cc.attrs.test} you can get the current value (null) or set a new value but
you cannot get the type of the property (e.g. String[]). However if the
property in the managed bean is non-null you can get the type.
For example:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- calling #{cc.attrs.test}.getType() will fail if #{cc.attrs.test} resolves
to null, but will work if #{cc.attrs.test} resolves to some valid value.
This currently results in a NullPointerException in
_SharedRendererUtils.getConvertedUISelectManyValue().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+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
[jira] [Commented] (MYFACES-2552) TagValueExpression.getType() returns null if the property in the managed bean is null and the expression points to a facelets composite component attribute
[
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 there are several ways to make it work
(with detours). But I am convinced this should be fixed as IMO this is basic
functionality.
TagValueExpression.getType() returns null if the property in the managed bean
is null and the expression points to a facelets composite component attribute
---
Key: MYFACES-2552
URL: https://issues.apache.org/jira/browse/MYFACES-2552
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.0
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2552-spec-proposal.patch
if you have a facelets composite component with an attribute test that
points to a property in a managed bean (e.g. #{myBean.property}) which is
currently null and you refer to that attribute in the implementation via
#{cc.attrs.test} you can get the current value (null) or set a new value but
you cannot get the type of the property (e.g. String[]). However if the
property in the managed bean is non-null you can get the type.
For example:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- calling #{cc.attrs.test}.getType() will fail if #{cc.attrs.test} resolves
to null, but will work if #{cc.attrs.test} resolves to some valid value.
This currently results in a NullPointerException in
_SharedRendererUtils.getConvertedUISelectManyValue().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-227) @Advanced not working correctly with Ajax
[ https://issues.apache.org/jira/browse/EXTCDI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13108614#comment-13108614 ] Michael Kurz commented on EXTCDI-227: - I just analyzed the problem with Gerhard and it seems to occur in RestoreInjectionPointsObserver. Inside processComponents() getChildren() is used to walk the tree which does not work for components inside composite components. @Advanced not working correctly with Ajax - Key: EXTCDI-227 URL: https://issues.apache.org/jira/browse/EXTCDI-227 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 1.0.2 Reporter: Michael Kurz Priority: Minor Attachments: EXTCDI-227-testapp.zip I have a converter annotated with @Advanced that gets a bean injected into a field via @Inject. On first page view the converter works as expected, but in subsequent ajax requests the field annotated with @Inject is not injected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3311) Can't resolve converter for cc attributes
Can't resolve converter for cc attributes
-
Key: MYFACES-3311
URL: https://issues.apache.org/jira/browse/MYFACES-3311
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.3
Reporter: Michael Kurz
I have some serious problems with composite component attributes. I have a
composite component with the attribute value. This attribute
(#{cc.attrs.value}) is mapped to the value attribute of an internal
h:inputText. When I pass a VE to the composite component, the value is not
converted in the h:inputText.
The problem is caused in _SharedRendererUtils.findUIOutputConverter(). In this
method the converter is resolved based on the type returned by a call to
getType() on the VE. Unfortunately, for the VE in the composite component
(#{cc.attrs.value}) this resolves to java.lang.Object (and not to
java.lang.Long in my case).
I quickly tried to replace the call to VE.getType() with a call to
getValue().getClass(). This works, but I guess this introduces additional
constraints I'm currently not aware of. Any ideas? Wasn't something like this
already discussed in the past?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-227) @Advanced not working correctly with Ajax
@Advanced not working correctly with Ajax - Key: EXTCDI-227 URL: https://issues.apache.org/jira/browse/EXTCDI-227 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 1.0.2 Reporter: Michael Kurz I have a converter annotated with @Advanced that gets a bean injected into a field via @Inject. On first page view the converter works as expected, but in subsequent ajax requests the field annotated with @Inject is not injected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-227) @Advanced not working correctly with Ajax
[ https://issues.apache.org/jira/browse/EXTCDI-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107841#comment-13107841 ] Michael Kurz commented on EXTCDI-227: - Additional info: Using the bean manager to resolve the bean that should be injected works like expected. @Advanced not working correctly with Ajax - Key: EXTCDI-227 URL: https://issues.apache.org/jira/browse/EXTCDI-227 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 1.0.2 Reporter: Michael Kurz Attachments: EXTCDI-227-testapp.zip I have a converter annotated with @Advanced that gets a bean injected into a field via @Inject. On first page view the converter works as expected, but in subsequent ajax requests the field annotated with @Inject is not injected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3308) Allow localized composite components
Allow localized composite components Key: MYFACES-3308 URL: https://issues.apache.org/jira/browse/MYFACES-3308 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz I tried to make a localized composite components for dynamic localization of content on my pages (that goes beyond resource bundles). The basic idea is to be able to create composite components with static text and/or components (links, images...) for different languages. As a composite component basically is a resource I thought something like this should be possible: /resources/fragments/fragment01.xhtml /resources/de/fragments/fragment01.xhtml IMO the spec is a bit unclear on this but I would say it should work. I tried it - it did not work. The problem is, that CompositeComponentResourceTagHandler gets a resource in the constructor that will be used till the death of the webapp. No chance to switch locales. My idea is to use a cache holding a resource for every locale. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3308) Allow localized composite components
[ https://issues.apache.org/jira/browse/MYFACES-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-3308: -- Status: Patch Available (was: Open) Allow localized composite components Key: MYFACES-3308 URL: https://issues.apache.org/jira/browse/MYFACES-3308 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.1.3 Reporter: Michael Kurz I tried to make a localized composite components for dynamic localization of content on my pages (that goes beyond resource bundles). The basic idea is to be able to create composite components with static text and/or components (links, images...) for different languages. As a composite component basically is a resource I thought something like this should be possible: /resources/fragments/fragment01.xhtml /resources/de/fragments/fragment01.xhtml IMO the spec is a bit unclear on this but I would say it should work. I tried it - it did not work. The problem is, that CompositeComponentResourceTagHandler gets a resource in the constructor that will be used till the death of the webapp. No chance to switch locales. My idea is to use a cache holding a resource for every locale. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
MyFaces Commons not building
Hi guys, I tried to build MyFaces Commons 2.0 (branch jsf_20) and get build errors. It seems that the class AdvancedResourceHandler is referenced in several places but does not exist anymore. Maybe a refactoring gone wrong? Yesterday the build was OK. cheers Michael
Re: [VOTE] release of myfaces core 2.1.3
+1 (works for me now) Am 13.09.2011 um 20:44 schrieb Gerhard Petracek: +1 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/13 Grant Smith work.gr...@gmail.com +1 On Tue, Sep 13, 2011 at 3:09 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2011/9/13 Werner Punz werner.p...@gmail.com: +1 Am 13.09.11 05:44, schrieb Leonardo Uribe: +1 2011/9/12 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() * [MYFACES-3301] - ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-055/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- 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.
[jira] [Commented] (MYFACES-3306) h:selectManyCheckBox + JPA with Hibernate creates Hibernate PersistentCollection where it should not. Causes
[
https://issues.apache.org/jira/browse/MYFACES-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104566#comment-13104566
]
Michael Kurz commented on MYFACES-3306:
---
There might be a simpler solution. Try to add
f:attribute name=collectionType value=java.util.HashSet/
as a child to h:selectManyCheckBox.
h:selectManyCheckBox + JPA with Hibernate creates Hibernate
PersistentCollection where it should not. Causes
---
Key: MYFACES-3306
URL: https://issues.apache.org/jira/browse/MYFACES-3306
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.2
Environment: JPA with Hibernate + Spring
Reporter: Kristian Jörg
Original Estimate: 24h
Remaining Estimate: 24h
I have a case where I use a JPA domain object (Mission) that has a standard
@ManyToMany relationship to another domain object Departments. The fetch type
is set to EAGER on both ends.
The web page has a h:selectManyCheckBox with all possible Departments. The
selection is then mapped to the mission object's department set via a custom
converter. This all works well.
When I submit my form I get an org.hibernate.LazyInitializationException in
(I believe) the validation phase. The problem is that MyFaces tries to
create a new instance of the specific hibernate class PersistentSet (which
should NOT be used outside Hibernate). It then populates this Set with
objects and that is when LazyInitializationException hits!
I have pinpointed the exact location to
org.apache.myfaces.shared_impl.renderkit.SharedRendererUtils.java, Line 255:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null
? componentValue.getClass()
: modelType).newInstance();
}
With I add a check so we are not instanciating Hibernate collections
(AbstractPersistentCollection) the program then goes on to create a standard
HashSet and all is well. My program works perfectly with this patch:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null !(componentValue instanceof
org.hibernate.collection.AbstractPersistentCollection)
? componentValue.getClass()
: modelType).newInstance();
}
Of course, adding a dependency on Hibernate in Myfaces is not the correct
solution, so another solution has to be invented.
My program is solid in itself with regards to the dreaded LIE exception, it
is only when I use persisted objects with OneToMany or ManyToMany collections
that this problem occurs.
MyFaces should never try to instanciate Hibernate collections without having
an entity manager session, which you do not.
I can attach some code examples if needed, but the problem lies not in the
rather standard JSF code, but in this specific point in code listed above.
Let me know if more examples are needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3306) h:selectManyCheckBox + JPA with Hibernate creates Hibernate PersistentCollection where it should not. Causes
[
https://issues.apache.org/jira/browse/MYFACES-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105122#comment-13105122
]
Michael Kurz commented on MYFACES-3306:
---
So, I quickly checked it again. You can also add it directly as attribute
collectionType=java.util.HashSet to h:selectManyCheckBox. I think this was
added in JSF 2.0.
IMO this is the recommended way to do it. If there is no objection from the
community I would say this issue can be closed.
h:selectManyCheckBox + JPA with Hibernate creates Hibernate
PersistentCollection where it should not. Causes
---
Key: MYFACES-3306
URL: https://issues.apache.org/jira/browse/MYFACES-3306
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.2
Environment: JPA with Hibernate + Spring
Reporter: Kristian Jörg
Original Estimate: 24h
Remaining Estimate: 24h
I have a case where I use a JPA domain object (Mission) that has a standard
@ManyToMany relationship to another domain object Departments. The fetch type
is set to EAGER on both ends.
The web page has a h:selectManyCheckBox with all possible Departments. The
selection is then mapped to the mission object's department set via a custom
converter. This all works well.
When I submit my form I get an org.hibernate.LazyInitializationException in
(I believe) the validation phase. The problem is that MyFaces tries to
create a new instance of the specific hibernate class PersistentSet (which
should NOT be used outside Hibernate). It then populates this Set with
objects and that is when LazyInitializationException hits!
I have pinpointed the exact location to
org.apache.myfaces.shared_impl.renderkit.SharedRendererUtils.java, Line 255:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null
? componentValue.getClass()
: modelType).newInstance();
}
With I add a check so we are not instanciating Hibernate collections
(AbstractPersistentCollection) the program then goes on to create a standard
HashSet and all is well. My program works perfectly with this patch:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null !(componentValue instanceof
org.hibernate.collection.AbstractPersistentCollection)
? componentValue.getClass()
: modelType).newInstance();
}
Of course, adding a dependency on Hibernate in Myfaces is not the correct
solution, so another solution has to be invented.
My program is solid in itself with regards to the dreaded LIE exception, it
is only when I use persisted objects with OneToMany or ManyToMany collections
that this problem occurs.
MyFaces should never try to instanciate Hibernate collections without having
an entity manager session, which you do not.
I can attach some code examples if needed, but the problem lies not in the
rather standard JSF code, but in this specific point in code listed above.
Let me know if more examples are needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
Ajax behavior change from 2.1.1 to 2.1.2 Key: MYFACES-3300 URL: https://issues.apache.org/jira/browse/MYFACES-3300 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Michael Kurz I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved. With 2.1.2 I have two issues: 1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again. 2) Now validation kicks in for invalid values and I get an error message in the browser This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1). Would be interesting to know what really changed here! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
[ https://issues.apache.org/jira/browse/MYFACES-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100146#comment-13100146 ] Michael Kurz commented on MYFACES-3300: --- Hi Jakob, I have already checked the release notes and found nothing in this direction. See the attached an example. Ajax behavior change from 2.1.1 to 2.1.2 Key: MYFACES-3300 URL: https://issues.apache.org/jira/browse/MYFACES-3300 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Michael Kurz Attachments: MYFACES-3300-test.zip I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved. With 2.1.2 I have two issues: 1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again. 2) Now validation kicks in for invalid values and I get an error message in the browser This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1). Would be interesting to know what really changed here! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1
+1 cheers Michael Original-Nachricht Datum: Mon, 6 Dec 2010 18:35:28 + (GMT) Von: Mark Struberg strub...@yahoo.de An: MyFaces Development dev@myfaces.apache.org Betreff: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1 did some test runs with our app and it looks very good. Artifacts and source-release looks fine too. +1 LieGrue, strub --- On Mon, 12/6/10, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf mat...@apache.org Subject: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1 To: MyFaces Development dev@myfaces.apache.org Date: Monday, December 6, 2010, 6:21 PM +1 On Mon, Dec 6, 2010 at 3:58 AM, Gerhard Petracek gpetra...@apache.org wrote: Hi, We were running the needed tasks to get the 2nd release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules Please take a look at the 0.9.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-050/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-050/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.1/myfaces-extcdi-parent-0.9.1-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.0
+1 Tested it in two apps (one with with OWB the other on Glassfish) and works great! cheers Michi Original-Nachricht Datum: Wed, 10 Nov 2010 08:36:40 +0100 Von: Matthias Wessendorf mat...@apache.org An: MyFaces Development dev@myfaces.apache.org Betreff: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.0 +1 On Wed, Nov 10, 2010 at 6:11 AM, Martin Marinschek mmarinsc...@apache.org wrote: +1, best regards, Martin On 11/10/10, Hazem Saleh haz...@apache.org wrote: +1. On Tue, Nov 9, 2010 at 11:12 PM, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub PS: we will add binary releases as next step, but they are not mandotory for an ASF release anyway (only the source-release is needed) --- On Tue, 11/9/10, Gerhard Petracek gpetra...@apache.org wrote: From: Gerhard Petracek gpetra...@apache.org Subject: [VOTE] Release of Extensions CDI (CODI) 0.9.0 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, November 9, 2010, 9:02 PM Hi, We were running the needed tasks to get the 1st release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Distribution Modules Please take a look at the 0.9.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-052/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-052/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.0/myfaces-extcdi-parent-0.9.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://www.jroller.com/HazemBlog [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/ -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: PageFlowScopeProvider development request
Hi, I created an issue some time ago for this [1] including a description of the original problem and some first implementation snippets. Those snippets do not exactly fit the window manager api that is already part of Trinidad. So I really wonder if an implementation of this api is already floating around somewhere. As the api exists I guess that somebody must have an idea why it was built that why and how the implementation should look like. Some code would be very welcome. regards Michael Am 15.08.2010 21:15, schrieb Michael Kurz: Hi Blake, I will look into this issue for Mark. So far, I have already looked at some of the code involved here. Furthermore, I created a very basic WindowManager implementation for playing around. As support for windows is already implemented in the state handler, I managed to get a simple version up and running (just for simple post backs). I think the first challenge here is to get a bullet-proof window detection (if something like this is possible). Because if the state is stored per window and the current window is lost we will definitly run into problems (back button...). Do you already have some ideas or an implementation for this? I think you mentioned something like this a while ago. regards Michael Am 06.08.2010 20:12, schrieb Blake Sullivan: Mark, I believe that what you really need is a default WindowManager implementation in Trinidad. When a WindowManager is present, Trinidad will store the view state under the windows and the view state can be cleaned up when the window is closed. -- Blake Sullivan On 7/27/10 9:24 PM, Mark Badorrek wrote: Developers, I have a Trinidad application that has a few independant frames that operate in a non-modal fashion (The client needs tha app to work this way). All frames extensively use 'PageFlowScope'. Now PageFlowScope works well if you have a single frame, but gives no end of grief if you have multipe frames. This can be explained: Every time a user clicks on a page, Trinidad creates another viewstate object and shoves it onto the pageflowscope map. The map is stored in the HTTP session and is not limitless. You set the size of the map in web.xml. Once you start adding viewstates to an already-full map, the map starts discarding the oldest viewstates. Ususally this is not a problem (how many times could a user be expected to click the 'Back' button?) But if you have multiple frames, the user could spend 30minutes clicking in frame 'B', whilst the current viewstate of frame 'A' becomes older and older and eventually gets pushed out of the viewstate map. The the user clicks on frame 'A', the viewstate is not found and everything falls in a smoking mess. You can get around this by specifying a huge map-size in web.xml but this results in spectacular memory wastage for no really good reason. An alternative is to implement a new pageFlowScopeProvider that keeps separate maps for each frame. Trinidad does not have one of these out-of-the-box, but I have written one for my client. The problem is that it would be better to imlement this as a general solution in Trinidad so that others may benefit (and also that my client doesn't have to maintain it). I've not been involved in the project for a while but I'd like to get a solution in place for my client. Is there a preferred method to avoid the above problem? Or should the custome PageFlowScopeProvider be pursued? If the reccomendation is to pursue a custom pageFlowScopeProvider, my client (a government client) is happy to enter into a commercial arangement with a committer here. i.e. they will pay for a solution. Either to yourself of the Apache foundation etc. My code is available if it helps. Cheers, MarkB The information in this e-mail is intended for the named recipient only. It may contain privileged and/or confidential information. If you are not the intended recipient, you must not disclose, copy, distribute, take any action or reliance on it. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail. Warning: E-mail transmission cannot be guaranteed to be secure or error-free. The recipient should check this email and any attachments for the presence of viruses. The sender does not accept liability for any errors or omissions in the contents of this message.
[jira] Created: (TRINIDAD-1903) Window manager and per window page flow scope
Window manager and per window page flow scope
-
Key: TRINIDAD-1903
URL: https://issues.apache.org/jira/browse/TRINIDAD-1903
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.14-core
Reporter: Michael Kurz
Priority: Minor
Some time ago Mark Badorrek posted a development request for a
PageFlowScopeProvider that supports having one page flow scope and one view
cache for every window /tab of the browser. The original request explaining the
problem can be found at [1]. Mark has a working solution for this problem that
supports five hardcoded page flow scopes and view caches (details below).
What he wants to have is a generic solution that comes as part of Trinidad.
Blake suggested that this should be done with a window manager implementation.
I started working on this and provide some very basic code to discuss the
problems involved.
Details for the existing solution:
---
Mark's existing solution mainly consists of a custom page flow scope provider
implementation. This implementation supports a default page flow scope map and
five additional scope maps with predefined names. The names are supplied via
request parameters.
Additionally, they have a custom state manager that also checked the request
parameters and store a separate view cache for each of the five named windows
(including a default view cache).
The following scenario demonstrates how this solution is used. If the user
clicks on a link, a new window using a new page flow scope and view cache is
opened. The JSP fragment looks like this:
tr:goLink textAndAccessKey=... destination=#
onclick=window.open( '#{myBackingBean.getURL}', '...'/
public class MyBackingBean{
public void getURL(){
MapString, Object pageFlowScope = ThePageFlowProviderImpl.
getEmptyPageFlowScopeForRelatedWorkItems();
// Initialize some stuff and put it in the new page flow scope
pageFlowScope.put(key, value);
return ../my/new/frame.jsp? + ThePageFlowProviderImpl.
RELATED_WORK_ITEMS_PAGE_FLOW_SCOPE + =true;
}
}
Effectively the URL assigned to the goLink tag becomes :
../my/new/frame.jsp?relatedworkitems_pageflowscope=true
Once trinidad opens the new window and begins to create the view, it eventually
starts using the new page flow scope defined by the magic key in the URL
(relatedworkitems_pageflowscope) to determine which pageflowscope to use.
---
[1]: http://markmail.org/message/ijyve7oj2ik5l57k
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: PageFlowScopeProvider development request
Hi Blake, any news on this one? best regards Michael Am 15.08.2010 21:15, schrieb Michael Kurz: Hi Blake, I will look into this issue for Mark. So far, I have already looked at some of the code involved here. Furthermore, I created a very basic WindowManager implementation for playing around. As support for windows is already implemented in the state handler, I managed to get a simple version up and running (just for simple post backs). I think the first challenge here is to get a bullet-proof window detection (if something like this is possible). Because if the state is stored per window and the current window is lost we will definitly run into problems (back button...). Do you already have some ideas or an implementation for this? I think you mentioned something like this a while ago. regards Michael Am 06.08.2010 20:12, schrieb Blake Sullivan: Mark, I believe that what you really need is a default WindowManager implementation in Trinidad. When a WindowManager is present, Trinidad will store the view state under the windows and the view state can be cleaned up when the window is closed. -- Blake Sullivan On 7/27/10 9:24 PM, Mark Badorrek wrote: Developers, I have a Trinidad application that has a few independant frames that operate in a non-modal fashion (The client needs tha app to work this way). All frames extensively use 'PageFlowScope'. Now PageFlowScope works well if you have a single frame, but gives no end of grief if you have multipe frames. This can be explained: Every time a user clicks on a page, Trinidad creates another viewstate object and shoves it onto the pageflowscope map. The map is stored in the HTTP session and is not limitless. You set the size of the map in web.xml. Once you start adding viewstates to an already-full map, the map starts discarding the oldest viewstates. Ususally this is not a problem (how many times could a user be expected to click the 'Back' button?) But if you have multiple frames, the user could spend 30minutes clicking in frame 'B', whilst the current viewstate of frame 'A' becomes older and older and eventually gets pushed out of the viewstate map. The the user clicks on frame 'A', the viewstate is not found and everything falls in a smoking mess. You can get around this by specifying a huge map-size in web.xml but this results in spectacular memory wastage for no really good reason. An alternative is to implement a new pageFlowScopeProvider that keeps separate maps for each frame. Trinidad does not have one of these out-of-the-box, but I have written one for my client. The problem is that it would be better to imlement this as a general solution in Trinidad so that others may benefit (and also that my client doesn't have to maintain it). I've not been involved in the project for a while but I'd like to get a solution in place for my client. Is there a preferred method to avoid the above problem? Or should the custome PageFlowScopeProvider be pursued? If the reccomendation is to pursue a custom pageFlowScopeProvider, my client (a government client) is happy to enter into a commercial arangement with a committer here. i.e. they will pay for a solution. Either to yourself of the Apache foundation etc. My code is available if it helps. Cheers, MarkB The information in this e-mail is intended for the named recipient only. It may contain privileged and/or confidential information. If you are not the intended recipient, you must not disclose, copy, distribute, take any action or reliance on it. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail. Warning: E-mail transmission cannot be guaranteed to be secure or error-free. The recipient should check this email and any attachments for the presence of viruses. The sender does not accept liability for any errors or omissions in the contents of this message.
Re: JSF 2.0 and jetty:run
Hi, with jetty:run it was not possible to configure managed beans etc. with annotations. Both MyFaces and Mojarra scan java class files in /WEB-INF/lib and /WEB-INF/classes for this purpose. If you start a webapp with jetty:run, those directories do not exist until now. With the patch jetty creates virtual directories for those locations. cheers Michi Am 19.08.2010 11:23, schrieb Bruno Aranda: I wonder what was the problem with Jetty? I have been using mvn jetty:run with JSF 2 for quite a while... Bruno On 19 August 2010 05:28, Martin Marinschek mmarinsc...@apache.org mailto:mmarinsc...@apache.org wrote: Hi Michi, thanks, that will make it a tad easier for everyone using JSF and Jetty... best regards, Martin On Wed, Aug 18, 2010 at 9:21 PM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: On Wed, Aug 18, 2010 at 8:07 PM, Michael Kurz michi.k...@gmx.at mailto:michi.k...@gmx.at wrote: Patch for [2] is already committed, fast guys over there... +1 they rock and they are fast. thanks for sharing! -M Am 18.08.2010 19:48, schrieb Michael Kurz: Hi, I just saw that my patch for the maven jetty plugin ([1]) was accepted and is integrated in the latest version 7.2.0-SNAPSHOT. It is now possible to run JSF 2.0 projects with mvn jetty:run (at least in theory, there is another bug I provided a patch for [2]). Unfortunately, thre does not seem to be a snapshot repository for Jetty. So, whoever wants to try it has to build it first. cheers Michi [1]: http://jira.codehaus.org/browse/JETTY-1107 [2]: http://jira.codehaus.org/browse/JETTY-1261 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [DISCUSS] getting rid of all java.net maven repositories
Am 19.08.2010 16:58, schrieb Mark Struberg: I just figured that we still pretty often use the java.net maven repositories. They are not well maintained and often lead to weird problems. Today I tried to compile tomahawk and got a weird exception that shale-master-1.pom is broken. Had the same problem some time ago. I think what happened was that the specified repository location issued a redirect which was, for whatever reason, stored in my local pom file! I think what I did then was to manually download the pom. Also, if we use Java JSR spec APIs we should always rely on geronimo spec jars [1] instead of pulling them from the java.net repo! Geronimo spec jars are always IP cleared which is _not_ guaranteed in the java.net repo. +1 We should upgrade tomahawk to myfaces-parent-9 and try to get rid of arbitrary repositories. +1 Michi
Re: [VOTE] release for myfaces master pom 9
+1 I also tried it with Tomahawk. Build was fine but there was an issue with building the site. But as the mster pom version there is still 6, this is most likely not a problem in the new master pom. Michi Am 18.08.2010 11:31, schrieb Jakob Korherr: +1 Everything looks fine! Regards, Jakob 2010/8/18 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com +1 2010/8/17 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the version 9 release of Apache MyFaces Master POM. The plugins updated on this pom has been checked to work with maven site plugin 2.1.1 and no changes were required from previous proposed artifacts. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.myfaces v 9 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 9 pom and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-122/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/myfaces/9/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
JSF 2.0 and jetty:run
Hi, I just saw that my patch for the maven jetty plugin ([1]) was accepted and is integrated in the latest version 7.2.0-SNAPSHOT. It is now possible to run JSF 2.0 projects with mvn jetty:run (at least in theory, there is another bug I provided a patch for [2]). Unfortunately, thre does not seem to be a snapshot repository for Jetty. So, whoever wants to try it has to build it first. cheers Michi [1]: http://jira.codehaus.org/browse/JETTY-1107 [2]: http://jira.codehaus.org/browse/JETTY-1261
Re: JSF 2.0 and jetty:run
Patch for [2] is already committed, fast guys over there... Am 18.08.2010 19:48, schrieb Michael Kurz: Hi, I just saw that my patch for the maven jetty plugin ([1]) was accepted and is integrated in the latest version 7.2.0-SNAPSHOT. It is now possible to run JSF 2.0 projects with mvn jetty:run (at least in theory, there is another bug I provided a patch for [2]). Unfortunately, thre does not seem to be a snapshot repository for Jetty. So, whoever wants to try it has to build it first. cheers Michi [1]: http://jira.codehaus.org/browse/JETTY-1107 [2]: http://jira.codehaus.org/browse/JETTY-1261
Re: State of the scripts
Hi Werner, I tried out tutorial examples with the current trunk and it works like a charm (and fast like hell). Michi Am 15.08.2010 22:18, schrieb Werner Punz: Hi everyone, as it seems with my next commit tomorrow we will get another small speed boost. I have a testcase which runs about ppr 500 requests in a crossform submit and so far the numbers look good. a) We are now down to basically zero mem leaks and dom leaks on ie6 and have about 30% more speed than mojarra which still is leaking dom nodes and mem. I assume the numbers are similar on ie7, given that dom leaks are a major performance killer on ie. b) We are bascially at the same performance on firefox 3.6 maybe slightly faster now (hard to measure) c) Slightly Faster on Firefox 4 d) Mojarra failed on chrome and opera, my testcase works on both browsers in myfaces. I guess the 2.0.2 release will be a major performance improvement in all areas. I have some testing to do especially for the part I have added for Martin Koci but then I will commit the latest codebase.
Re: PageFlowScopeProvider development request
Hi Blake, I will look into this issue for Mark. So far, I have already looked at some of the code involved here. Furthermore, I created a very basic WindowManager implementation for playing around. As support for windows is already implemented in the state handler, I managed to get a simple version up and running (just for simple post backs). I think the first challenge here is to get a bullet-proof window detection (if something like this is possible). Because if the state is stored per window and the current window is lost we will definitly run into problems (back button...). Do you already have some ideas or an implementation for this? I think you mentioned something like this a while ago. regards Michael Am 06.08.2010 20:12, schrieb Blake Sullivan: Mark, I believe that what you really need is a default WindowManager implementation in Trinidad. When a WindowManager is present, Trinidad will store the view state under the windows and the view state can be cleaned up when the window is closed. -- Blake Sullivan On 7/27/10 9:24 PM, Mark Badorrek wrote: Developers, I have a Trinidad application that has a few independant frames that operate in a non-modal fashion (The client needs tha app to work this way). All frames extensively use 'PageFlowScope'. Now PageFlowScope works well if you have a single frame, but gives no end of grief if you have multipe frames. This can be explained: Every time a user clicks on a page, Trinidad creates another viewstate object and shoves it onto the pageflowscope map. The map is stored in the HTTP session and is not limitless. You set the size of the map in web.xml. Once you start adding viewstates to an already-full map, the map starts discarding the oldest viewstates. Ususally this is not a problem (how many times could a user be expected to click the 'Back' button?) But if you have multiple frames, the user could spend 30minutes clicking in frame 'B', whilst the current viewstate of frame 'A' becomes older and older and eventually gets pushed out of the viewstate map. The the user clicks on frame 'A', the viewstate is not found and everything falls in a smoking mess. You can get around this by specifying a huge map-size in web.xml but this results in spectacular memory wastage for no really good reason. An alternative is to implement a new pageFlowScopeProvider that keeps separate maps for each frame. Trinidad does not have one of these out-of-the-box, but I have written one for my client. The problem is that it would be better to imlement this as a general solution in Trinidad so that others may benefit (and also that my client doesn't have to maintain it). I've not been involved in the project for a while but I'd like to get a solution in place for my client. Is there a preferred method to avoid the above problem? Or should the custome PageFlowScopeProvider be pursued? If the reccomendation is to pursue a custom pageFlowScopeProvider, my client (a government client) is happy to enter into a commercial arangement with a committer here. i.e. they will pay for a solution. Either to yourself of the Apache foundation etc. My code is available if it helps. Cheers, MarkB The information in this e-mail is intended for the named recipient only. It may contain privileged and/or confidential information. If you are not the intended recipient, you must not disclose, copy, distribute, take any action or reliance on it. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail. Warning: E-mail transmission cannot be guaranteed to be secure or error-free. The recipient should check this email and any attachments for the presence of viruses. The sender does not accept liability for any errors or omissions in the contents of this message.
Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
I would also get rid of the author tags too. I guess that in many cases they are not correct anyway as files are constantly changed. Michael Am 11.08.2010 08:22, schrieb Matthias Wessendorf: On Tue, Aug 10, 2010 at 11:55 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, why we need the @author tag? I don't like code owner ship. well, some do. I am fine without. In fact a lot of Apache project do so, since there is no code-ownership. SVN has still all the information Does your request mean we don't allow the svn:keywords=Date Author Id Revision HeadURL in the Subversion config file? I am sure the talk is *only* inside the Java files, and not removing the metadata of the file. -M Regards Bernd On Tue, Aug 10, 2010 at 10:00 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Hi, Sure. For example, take a look at: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/FacesException.java If we remove the SVN stuff, we'll end up with this JavaDoc comment: /** * see Javadoc ofa href=http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/index.html;JSF Specification/a * * @author Manfred Geiler */ Or for example: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/Application.java This would become: /** * . * * @author Manfred Geiler * @author Stan Silvert */ One last example, a class added in 2.0: http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/application/ResourceHandler.java Which would end up like: /** * @author Simon Lessard * @since 2.0 */ What do you think? BTW. I'm thinking of the best way to do this. I guess the best bet is to do a massive find-replace on one project at a time. Generating a patch file would be a nice way to check for possible errors... Regards, Jan-Kees 2010/8/10 Leonardo Uribelu4...@gmail.com Hi Could you provide an explicit example about how the header of java files should be? best regards, Leonardo
[jira] Commented: (MYFACES-2515) Archetype for MyFaces 2.0 hello world app
[ https://issues.apache.org/jira/browse/MYFACES-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897258#action_12897258 ] Michael Kurz commented on MYFACES-2515: --- The OWB guys are discussing to release version 1.0.0 next week. We should maybe wait for them. Archetype for MyFaces 2.0 hello world app - Key: MYFACES-2515 URL: https://issues.apache.org/jira/browse/MYFACES-2515 Project: MyFaces Core Issue Type: New Feature Reporter: Michael Kurz Attachments: MYFACES-2515-2.patch, MYFACES-2515-3.patch, MYFACES-2515.patch I created an archetype for a MyFaces 2.0 hello world app. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2869) Ajaxified h:selectBooleanCheckbox not working in IE8
Ajaxified h:selectBooleanCheckbox not working in IE8
Key: MYFACES-2869
URL: https://issues.apache.org/jira/browse/MYFACES-2869
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.1, 2.0.0, 2.0.2-SNAPSHOT
Reporter: Michael Kurz
Attachments: MYFACES-2869.zip
I have an ajaxified h:selectBooleanCheckbox like this:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox/
/h:selectBooleanCheckbox
The value change listener toggles a boolean flag and the component with the id
textBox is re-rendered. This works fine with FF, Safari and Chrome but not
with IE8. The resaon for this is that the default onchange event is not working
correctly in IE8. In IE8 onchange is not triggered before the component looses
the focus. So I have to click the component and then again outside the
component to hav the ajax request sent.
A workaround for this is to set the event to click manually:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox event=click/
/h:selectBooleanCheckbox
The question now is, should we change the default event for
HtmlSelectBooleanCheckbox from change to click (or more precisely the mapping
of valueChange from change to click)? I quickly scanned the spec but I found
nothing helpful.
Mojarra seems to render an onclick attribute by default. But what is kind of
funny - with event=click on f:ajax it stops working...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2869) Ajaxified h:selectBooleanCheckbox not working in IE8
[
https://issues.apache.org/jira/browse/MYFACES-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896545#action_12896545
]
Michael Kurz edited comment on MYFACES-2869 at 8/9/10 9:47 AM:
---
Added a webapp to demonstrate this issue.
was (Author: dr.gonzo):
Webapp to demonstrate this issue.
Ajaxified h:selectBooleanCheckbox not working in IE8
Key: MYFACES-2869
URL: https://issues.apache.org/jira/browse/MYFACES-2869
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0, 2.0.1, 2.0.2-SNAPSHOT
Reporter: Michael Kurz
Attachments: MYFACES-2869.zip
I have an ajaxified h:selectBooleanCheckbox like this:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox/
/h:selectBooleanCheckbox
The value change listener toggles a boolean flag and the component with the
id textBox is re-rendered. This works fine with FF, Safari and Chrome but
not with IE8. The resaon for this is that the default onchange event is not
working correctly in IE8. In IE8 onchange is not triggered before the
component looses the focus. So I have to click the component and then again
outside the component to hav the ajax request sent.
A workaround for this is to set the event to click manually:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox event=click/
/h:selectBooleanCheckbox
The question now is, should we change the default event for
HtmlSelectBooleanCheckbox from change to click (or more precisely the mapping
of valueChange from change to click)? I quickly scanned the spec but I found
nothing helpful.
Mojarra seems to render an onclick attribute by default. But what is kind of
funny - with event=click on f:ajax it stops working...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2869) Ajaxified h:selectBooleanCheckbox not working in IE8
[
https://issues.apache.org/jira/browse/MYFACES-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896548#action_12896548
]
Michael Kurz commented on MYFACES-2869:
---
OK, this is a known issue in Mojarra:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1760
Ajaxified h:selectBooleanCheckbox not working in IE8
Key: MYFACES-2869
URL: https://issues.apache.org/jira/browse/MYFACES-2869
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0, 2.0.1, 2.0.2-SNAPSHOT
Reporter: Michael Kurz
Attachments: MYFACES-2869.zip
I have an ajaxified h:selectBooleanCheckbox like this:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox/
/h:selectBooleanCheckbox
The value change listener toggles a boolean flag and the component with the
id textBox is re-rendered. This works fine with FF, Safari and Chrome but
not with IE8. The resaon for this is that the default onchange event is not
working correctly in IE8. In IE8 onchange is not triggered before the
component looses the focus. So I have to click the component and then again
outside the component to hav the ajax request sent.
A workaround for this is to set the event to click manually:
h:selectBooleanCheckbox valueChangeListener=#{controller.change}
f:ajax render=textBox event=click/
/h:selectBooleanCheckbox
The question now is, should we change the default event for
HtmlSelectBooleanCheckbox from change to click (or more precisely the mapping
of valueChange from change to click)? I quickly scanned the spec but I found
nothing helpful.
Mojarra seems to render an onclick attribute by default. But what is kind of
funny - with event=click on f:ajax it stops working...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?)
+1 as keeping information where it belongs (in the SVN) is basically a good idea. General guidelines about what should be in the header of a file might be useful. regards Michael Am 09.08.2010 23:41, schrieb Mark Struberg: +1 because it's most times broken anyway ;) LieGrue, strub From: Gerhardgerhard.petra...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org Sent: Mon, August 9, 2010 11:22:34 PM Subject: Re: Proposal to stop using SVN Keywords - (was: MyFaces shipping with JBoss AS6?) +1 these are the reasons why you won't find such information in the extensions projects. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/8/9 Jan-Kees van Andeljankeesvanan...@gmail.com Hi, What do you guys think about pruning the SVN keywords in the source files? Matthias pointed out a nice example of an issue you run into with this stuff. 1 Not everybody has (the same) svn:keywords on every file. 2 When 1, it will get out of sync. 3 Unreadable version numbers are pretty useless information (at least for me). 4 If you need to know something about the revision history, SVN itself is a much better place to look. 5 (I think) it looks messy in the source code. Note that I'm not talking about removing everything in a major refactoring. For now, I'm just proposing a convention for new code. I'm also not proposing to remove the @author JavaDoc tag. That's a useful one. I'm talking about the latest modification by $Author and @version $Revision: 799929 $ $Date:...$ stuff. What do you guys think? Regards, Jan-Kees 2010/8/9 Jan-Kees van Andeljankeesvanan...@gmail.com Yeah, I know. I'm so quick. I can edit files back in time. ;-) /JK 2010/8/9 Matthias Wessendorfmat...@apache.org + * @author Leonardo Uribe (latest modification by $Author: jankeesvanandel $) + * @version $Revision: 799929 $ $Date: 2009-08-01 16:29:33 -0500 (sáb, 01 ago 2009) $ did you copy that into your IDE template for new files? :-) -M On Mon, Aug 9, 2010 at 7:25 PM, Leonardo Uribelu4...@gmail.com wrote: Hi Stan I have attached a proposal for this issue on: https://issues.apache.org/jira/browse/MYFACES-2860 It includes the patch to be applied on myfaces, the project created to do the integration, and the jsf deployer used in JBoss AS6 to give a try. It could be good to know what do yo think about it. best regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2515) Archetype for MyFaces 2.0 hello world app
[ https://issues.apache.org/jira/browse/MYFACES-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896371#action_12896371 ] Michael Kurz commented on MYFACES-2515: --- I provided a patch with updated library versions for the JSF 2.0 archetypes. I added it to this issue as it has never been closed. Will there be a release of version 1.0.2 of the archetypes (and the catalog) in the forseeable future? Archetype for MyFaces 2.0 hello world app - Key: MYFACES-2515 URL: https://issues.apache.org/jira/browse/MYFACES-2515 Project: MyFaces Core Issue Type: New Feature Reporter: Michael Kurz Attachments: MYFACES-2515-2.patch, MYFACES-2515-3.patch, MYFACES-2515.patch I created an archetype for a MyFaces 2.0 hello world app. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2859) Replacing elements for ajax response changes element order
Replacing elements for ajax response changes element order -- Key: MYFACES-2859 URL: https://issues.apache.org/jira/browse/MYFACES-2859 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1, 2.0.2-SNAPSHOT Reporter: Michael Kurz In my application processing the ajax response for a ajax request changes the order of the elements. I have an html input element with siblings in a div that is replaced with a script and the new input element in the ajax response. The problem is, that the new input element is inserted after the siblings of the original element thus reversing the order of the elements I think the problem is in the replaceElements function in _Dom.js. There, oldNode.nextSibling always returns null. I created a patch that solves this issue, but I am not sure if there are any side effects. Master of Ajax (Werner) please have a look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2859) Replacing elements for ajax response changes element order
[ https://issues.apache.org/jira/browse/MYFACES-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-2859: -- Status: Patch Available (was: Open) Replacing elements for ajax response changes element order -- Key: MYFACES-2859 URL: https://issues.apache.org/jira/browse/MYFACES-2859 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1, 2.0.2-SNAPSHOT Reporter: Michael Kurz Attachments: MYFACES-2859.patch In my application processing the ajax response for a ajax request changes the order of the elements. I have an html input element with siblings in a div that is replaced with a script and the new input element in the ajax response. The problem is, that the new input element is inserted after the siblings of the original element thus reversing the order of the elements I think the problem is in the replaceElements function in _Dom.js. There, oldNode.nextSibling always returns null. I created a patch that solves this issue, but I am not sure if there are any side effects. Master of Ajax (Werner) please have a look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
