Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punz werner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
There is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punz werner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Thats what I am working on, my personal idea is, to run the tests and then have a final result page which then can be analyzed by selenium. Hence i was talking about having a server side statistics collector which collects all the results over all pages. It simply is better to have the tests themselves performed by javascript because there you can deal better with the dom and with the jsf lifecycle. In Selenium you only can issue wait ... seconds wheras my tests directly can intercept the jsf lifecycle with listeners. Werner Am 10/7/11 10:30 AM, schrieb Mark Struberg: I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
[jira] [Reopened] (TOBAGO-1011) Popup should determine its size automatically
[ https://issues.apache.org/jira/browse/TOBAGO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann reopened TOBAGO-1011: --- Assignee: Bernd Bohmann (was: Udo Schnurpfeil) We should postpone this change, because it is not backwards compatible. Popup should determine its size automatically - Key: TOBAGO-1011 URL: https://issues.apache.org/jira/browse/TOBAGO-1011 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Fix For: 1.5.0-beta-1, 1.5.0 The popup should get an different configured default layout manager: Default for tc:page, tc:panel, tc:box is grid-layout with columns=* and rows=*. For popups we should use grid-layout with column=auto and rows=auto. This will make the popup will be rendered in the size it needs and no explicit width and height must be set. -- 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] (TOBAGO-1011) Popup should determine its size automatically
[ https://issues.apache.org/jira/browse/TOBAGO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-1011. --- Resolution: Won't Fix Fix Version/s: (was: 1.5.0-beta-1) (was: 1.5.0) It is not backwards compatible Popup should determine its size automatically - Key: TOBAGO-1011 URL: https://issues.apache.org/jira/browse/TOBAGO-1011 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann The popup should get an different configured default layout manager: Default for tc:page, tc:panel, tc:box is grid-layout with columns=* and rows=*. For popups we should use grid-layout with column=auto and rows=auto. This will make the popup will be rendered in the size it needs and no explicit width and height must be set. -- 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: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Hi Werner. Since I have had a lot of wait issues with ajax + Selenium testing my own JSF apps, I tried to take a look at what you were doing to see if I could write my own app jsf tests using your new framework. However, I am getting the following installation/build errors. I'm still on ant as I've never taken the time to learn the intricacies of maven, so I'm not sure what needs to be done to fix them. I'm guessing it's because snapshot files don't exist in the public repositories? So I'd either need to build my own snapshot files and install them as directed, or re-point maven to a specific released build version? Also, am I right in thinking your framework can be used for generic JSF app testing? Or is that some future goal not yet achieved? 1) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT On Fri, Oct 7, 2011 at 4:36 AM, Werner Punz werner.p...@gmail.com wrote: Thats what I am working on, my personal idea is, to run the tests and then have a final result page which then can be analyzed by selenium. Hence i was talking about having a server side statistics collector which collects all the results over all pages. It simply is better to have the tests themselves performed by javascript because there you can deal better with the dom and with the jsf lifecycle. In Selenium you only can issue wait ... seconds wheras my tests directly can intercept the jsf lifecycle with listeners. Werner Am 10/7/11 10:30 AM, schrieb Mark Struberg: I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
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/
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Werner, Well, I think I've answered my own question regarding the maven issues -- changing the version from 2.1.4-snapshot to 2.1.3 makes things work. One thing I noticed is that your starting link location of http://localhost:9080/TestScripts/; seems to be a broken link. Using http://localhost:9080/ and going from there seems to work. On Fri, Oct 7, 2011 at 10:03 AM, Mike Kienenberger mkien...@gmail.com wrote: Hi Werner. Since I have had a lot of wait issues with ajax + Selenium testing my own JSF apps, I tried to take a look at what you were doing to see if I could write my own app jsf tests using your new framework. However, I am getting the following installation/build errors. I'm still on ant as I've never taken the time to learn the intricacies of maven, so I'm not sure what needs to be done to fix them. I'm guessing it's because snapshot files don't exist in the public repositories? So I'd either need to build my own snapshot files and install them as directed, or re-point maven to a specific released build version? Also, am I right in thinking your framework can be used for generic JSF app testing? Or is that some future goal not yet achieved? 1) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT On Fri, Oct 7, 2011 at 4:36 AM, Werner Punz werner.p...@gmail.com wrote: Thats what I am working on, my personal idea is, to run the tests and then have a final result page which then can be analyzed by selenium. Hence i was talking about having a server side statistics collector which collects all the results over all pages. It simply is better to have the tests themselves performed by javascript because there you can deal better with the dom and with the jsf lifecycle. In Selenium you only can issue wait ... seconds wheras my tests directly can intercept the jsf lifecycle with listeners. Werner Am 10/7/11 10:30 AM, schrieb Mark Struberg: I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Re: Snapshot of myfaces-builder-plugin in pom.xml
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: 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] [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
Thanks! Am 07.10.2011 10:01 schrieb Michael Kurz michi.k...@gmx.at: 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/ 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/
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] [Created] (TRINIDAD-2145) The tr:selectOrderShuttle has rendering issues when in reorderOnly=true. Improper HTML
The tr:selectOrderShuttle has rendering issues when in reorderOnly=true.
Improper HTML
-
Key: TRINIDAD-2145
URL: https://issues.apache.org/jira/browse/TRINIDAD-2145
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.14-core
Environment: Fails on Unix and Windows, FF and ie
Reporter: Bob Hedlund
Priority: Minor
The tr:selectOrderShuttle has rendering issues when in reorderOnly=true.
The HTML generated is missing an opening tr tag.
This causes PPR calls on the page to fail.
The Solution is to change the java file SelectManyShuttleRenderer
(trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\renderkit\core\xhtml).
In the method
renderContainerRow(args) {args}
There is an if block:
if(!onlyOneList) {
}
This block bypasses rendering the first shuttle if in reorderOnly mode.
The rendering of the table row:
rw.startElement(tr,null);
needs to be moved out of the block, and rendered unconditionally for proper
html.
--
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] [Updated] (MYFACES-3304) NullPointerException using h:selectOneRadio with an enum
[
https://issues.apache.org/jira/browse/MYFACES-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3304:
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
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
Assignee: Leonardo Uribe
Priority: Minor
Fix For: 2.0.10, 2.1.4
Attachments: MYFACES-3304-1.patch
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(BasicProcessingFilter.java:214)
at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
at
net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:324)
at
net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
at
net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:220)
at
[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=13123039#comment-13123039
]
Leonardo Uribe commented on MYFACES-3313:
-
I checked the spec finally I found this on section JSF 2.0 section 7.5.2
Default ViewHandler Implementation:
... The getActionURL() method must fulfill the following responsibilities: ...
If the argument viewId has an extension, and this extension is mapping,
the result is contextPath + viewId. For example “/cardemo/chooseLocale.faces
...
So the example proposed is on the spec. I agree use /page01.jsf is bad practice
because the effective viewId when the view is created is /page01.xhtml . It is
a long story, but at the end a change was introduced in JSF 2.1 to
differentiate between physical and logical view ids
(ViewHandler.deriveLogicalViewId).
Anyway, since this is described on the spec we should fix our implementation of
getActionURL() method.
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] [Resolved] (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:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3313.
-
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
Assignee: Leonardo Uribe
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
Assignee: Leonardo Uribe
Fix For: 2.0.10, 2.1.4
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] [Resolved] (MYFACES-3348) Length Validator Message in Messages.properties
[
https://issues.apache.org/jira/browse/MYFACES-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3348.
-
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
Assignee: Leonardo Uribe
Thanks to Keith Wong for provide this patch
Length Validator Message in Messages.properties
---
Key: MYFACES-3348
URL: https://issues.apache.org/jira/browse/MYFACES-3348
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.0.9, 2.1.3
Reporter: Keith Wong
Assignee: Leonardo Uribe
Priority: Minor
Fix For: 2.0.10, 2.1.4
In Messages.properties, the following standard message text
javax.faces.validator.LengthValidator.MAXIMUM = {1}: Validation Error: Value
is greater than allowable maximum of ''{0}''
javax.faces.validator.LengthValidator.MINIMUM = {1}: Validation Error: Value
is less than allowable minimum of ''{0}''
should be
javax.faces.validator.LengthValidator.MAXIMUM = {1}: Validation Error: Length
is greater than allowable maximum of ''{0}''
javax.faces.validator.LengthValidator.MINIMUM = {1}: Validation Error: Length
is less than allowable minimum of ''{0}''
--
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: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Hi the unit testing framework is generic, however I have not isolated the classes needed to run them as separate package. (they rely on some myfaces core js classes) If you need help to use it for your own stuff ping me, and I will give you some help. The error you are getting is indeed because of the snapshot you can roll back the version to the 2.1.3 in the pom it should work nevertheless. Werner Am 10/7/11 4:03 PM, schrieb Mike Kienenberger: Hi Werner. Since I have had a lot of wait issues with ajax + Selenium testing my own JSF apps, I tried to take a look at what you were doing to see if I could write my own app jsf tests using your new framework. However, I am getting the following installation/build errors. I'm still on ant as I've never taken the time to learn the intricacies of maven, so I'm not sure what needs to be done to fix them. I'm guessing it's because snapshot files don't exist in the public repositories? So I'd either need to build my own snapshot files and install them as directed, or re-point maven to a specific released build version? Also, am I right in thinking your framework can be used for generic JSF app testing? Or is that some future goal not yet achieved? 1) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT On Fri, Oct 7, 2011 at 4:36 AM, Werner Punzwerner.p...@gmail.com wrote: Thats what I am working on, my personal idea is, to run the tests and then have a final result page which then can be analyzed by selenium. Hence i was talking about having a server side statistics collector which collects all the results over all pages. It simply is better to have the tests themselves performed by javascript because there you can deal better with the dom and with the jsf lifecycle. In Selenium you only can issue wait ... seconds wheras my tests directly can intercept the jsf lifecycle with listeners. Werner Am 10/7/11 10:30 AM, schrieb Mark Struberg: I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras Am 9/29/11 9:35 PM, schrieb Werner Punz: Hello everyone, I just wanted everyone to know, that I am currently in the process of cleaning up and dumping my jsf.js client side javascript integration tests collected over the last year onto apache extras. The project is hosted at http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/ and can be checked out via git. It is by far not done yet, so far i have converted about 20% of my usually manually run javascript tests to a small ajax jsf specific testing framework and also some server side statistic collection has yet to be done but you already can have a look. This project also in the future will be my primary workbench for the javascripts before merging them into the trunk and branches. You already can have a look and run the tests, the explanation can be found on the projects site. Werner Hi Just a short status update, I now have about 20 tests checked in with 13 testgroups. I also added Mojarra as optional test target. I found promptly three bugs, which I will forward to the Mojarra guys in the next week. The only stuff pending now is some cleanup and a server side test statistic so that we can get the test results into a final result page.
Git at the ASF
Hello! I thought to share [1] since some of you are 'interested' in git; The #CouchDB guys are now on git, at the ASF! Cheers! Matthias [1] http://git-wip-us.apache.org/repos/asf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras
Mike just to give a short intro if you look at this example https://gist.github.com/1271104 You see basically an example with one testgroup and one testcase What happens here is that a testgroup is specified which can hold one or more testcases and a simple ajax textcase is specified, with the default behavior. What happens is a) Internally a setup method is called which sets the system up it is overwritten in this case. b) a precondition method is called (currently not overwritten) if this method returns false then the test has failed and the execution on the test is stopped c) a run method is called which performs some runtime operation, in our case the ajax call is started d) a postcondition now is called after the ajax cycle has successfully completed which does the asserts e) a tearDown method is called internally Any error from the ajax side also would make the test fail Most of the tests follow this pattern, some inherit the standard testcases to adjust the control. Currently the tests simply are analyzed on group level and the logging output and final result of each group test are put into the browsers console and a console logging area. I will refine the API more now that I know other people are interested, but let me finish the server side statisitics collector first. Then I will stabilize the api, I am in some aspects still not quite happy with it. So expect some changes in the upcoming 2-3 weeks. Werner Am 10/7/11 4:16 PM, schrieb Mike Kienenberger: Werner, Well, I think I've answered my own question regarding the maven issues -- changing the version from 2.1.4-snapshot to 2.1.3 makes things work. One thing I noticed is that your starting link location of http://localhost:9080/TestScripts/; seems to be a broken link. Using http://localhost:9080/ and going from there seems to work. On Fri, Oct 7, 2011 at 10:03 AM, Mike Kienenbergermkien...@gmail.com wrote: Hi Werner. Since I have had a lot of wait issues with ajax + Selenium testing my own JSF apps, I tried to take a look at what you were doing to see if I could write my own app jsf tests using your new framework. However, I am getting the following installation/build errors. I'm still on ant as I've never taken the time to learn the intricacies of maven, so I'm not sure what needs to be done to fix them. I'm guessing it's because snapshot files don't exist in the public repositories? So I'd either need to build my own snapshot files and install them as directed, or re-point maven to a specific released build version? Also, am I right in thinking your framework can be used for generic JSF app testing? Or is that some future goal not yet achieved? 1) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT [...] Path to dependency: 1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT 2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT On Fri, Oct 7, 2011 at 4:36 AM, Werner Punzwerner.p...@gmail.com wrote: Thats what I am working on, my personal idea is, to run the tests and then have a final result page which then can be analyzed by selenium. Hence i was talking about having a server side statistics collector which collects all the results over all pages. It simply is better to have the tests themselves performed by javascript because there you can deal better with the dom and with the jsf lifecycle. In Selenium you only can issue wait ... seconds wheras my tests directly can intercept the jsf lifecycle with listeners. Werner Am 10/7/11 10:30 AM, schrieb Mark Struberg: I see. Is there a way to kick this tests with Selenium? Of course only with firefox - but better than nothing ;) LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 10:14 AM Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache extras T here is one small reason. The tests run directly in the browser instead of htmlunit (which has a lot of bugs, hence I shun it i already had two adjustments regarding it in other tests) So how do we run the tests in maven in 5 different browser engines, three of them being windows only. Dont get me wrong htmlunit is nice, but it does not give reliable results when it comes to javascript and emulating browser quirks. Thats the only reason. Werner Am 10/7/11 9:42 AM, schrieb Mark Struberg: woha, big +1 and thanks for the hard work. Btw, why not hosting it directly over here as a test module for MyFaces core which could get executed before doing releases? LieGrue, strub - Original Message - From: Werner Punzwerner.p...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Friday, October 7, 2011 8:57 AM
Re: Git at the ASF
Am 10/7/11 9:04 PM, schrieb Matthias Wessendorf: Hello! I thought to share [1] since some of you are 'interested' in git; The #CouchDB guys are now on git, at the ASF! Cheers! Matthias [1] http://git-wip-us.apache.org/repos/asf Git support is still beta but nevertheless this is good news that the ASF soon will support GIT officially. Werner
[jira] [Created] (EXTCDI-231) Cannot configure ProjectStage via properties file
Cannot configure ProjectStage via properties file --- Key: EXTCDI-231 URL: https://issues.apache.org/jira/browse/EXTCDI-231 Project: MyFaces CODI Issue Type: Bug Components: Core Affects Versions: 1.0.2 Reporter: Biergit myfaces-extcdi.properties is ignored for parameter ProjectStage -- 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
