[jira] Created: (TRINIDAD-1905) Problem with the JMeter HTTP Proxy
Problem with the JMeter HTTP Proxy -- Key: TRINIDAD-1905 URL: https://issues.apache.org/jira/browse/TRINIDAD-1905 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2, 1.2.13-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf When running upload stress-tests with JMEter, there is a bug in Trinidad, as noticed here: http://markmail.org/message/p624zgpd7h2klleg Stack: org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest GRAVE: java.io.IOException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:208) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:119) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:523) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:209) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:142) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1905) Problem with the JMeter HTTP Proxy
[ https://issues.apache.org/jira/browse/TRINIDAD-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906682#action_12906682 ] Matthias Weßendorf commented on TRINIDAD-1905: -- There was a similar thread on the JMeter list: http://markmail.org/message/v2brfsmz257uppy6 where thoughts are that the issue is in Trinidad Problem with the JMeter HTTP Proxy -- Key: TRINIDAD-1905 URL: https://issues.apache.org/jira/browse/TRINIDAD-1905 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core , 2.0.0-alpha-2 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf When running upload stress-tests with JMEter, there is a bug in Trinidad, as noticed here: http://markmail.org/message/p624zgpd7h2klleg Stack: org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest GRAVE: java.io.IOException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:208) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:119) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:523) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:209) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:142) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2911) OSGi Manifest: MyFaces API Bundle requires IMPL Bundle
[ https://issues.apache.org/jira/browse/MYFACES-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906686#action_12906686 ] Matthias Weßendorf commented on MYFACES-2911: - Yes, API and IMPL are somewhat tied - I am sure the RI api has same requirement Thx for updating the patch OSGi Manifest: MyFaces API Bundle requires IMPL Bundle -- Key: MYFACES-2911 URL: https://issues.apache.org/jira/browse/MYFACES-2911 Project: MyFaces Core Issue Type: Bug Components: General Environment: OSGi container Reporter: Frank Mittag Priority: Minor The MANIFEST.MF file of the org.apache.myfaces.core.api bundle/jar contains the entry: Require-Bundle: org.apache.myfaces.core.impl;bundle-version=2.0.1 So the API bundle requires the IMPL bundle to work. This is not needed and prevents scenarios where the e.g. two IMPL bundles just reference the same API bundle. The easiest solution is just to remove the entry. Frank -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Trinidad plugins: 2.0.2 release
Hi, I was running the needed tasks to get the 2.0.2 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.2 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad plugins: 2.0.2 release
+1 On Tue, Sep 7, 2010 at 9:23 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the 2.0.2 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.2 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces archetypes 1.0.2
+1 LieGrue, strub --- On Mon, 9/6/10, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: [VOTE] release for myfaces archetypes 1.0.2 To: MyFaces Development dev@myfaces.apache.org Date: Monday, September 6, 2010, 8:12 PM Hi, I was running the needed tasks to get the 1.0.2 release of Apache MyFaces Build Tools Archetypes out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.2 (only archetypes) The artifacts are deployed to the nexus repository [1]. The following issues have been addressed in this release: * MYFACES-2515 Archetype for MyFaces 2.0 hello world app * TRINIDAD-1904 Archetype for Trinidad 2.0 * Update archetypes structure to fit the new archetype plugin * Add license headers in various files * Update versions of MyFaces, Mojarra, Jetty, Trinidad To test the archetypes just do the following: Create a project from an archetype: mvn archetype:generate -DarchetypeCatalog=http://people.apache.org/~jakobk/m2_archetypes_102_release Choose an archetype from the list and enter values for groupId, artifactId and version. Then on the path of the generated archetype mvn clean jetty:run or for the 2.0 archetypes mvn clean jetty:run-exploded -PjettyConfig Then open http://localhost:8080 and see if everything works. Please take a look at the 1.0.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +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, Jakob [1] https://repository.apache.org/content/repositories/orgapachemyfaces-041/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Resolved: (MYFACESTEST-6) Module for automated webapp tests for MyFaces core + extensions
[ https://issues.apache.org/jira/browse/MYFACESTEST-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACESTEST-6. - Resolution: Fixed Resolving this issue, because GSoC is over and the integration is done. Module for automated webapp tests for MyFaces core + extensions --- Key: MYFACESTEST-6 URL: https://issues.apache.org/jira/browse/MYFACESTEST-6 Project: MyFaces Test Issue Type: New Feature Reporter: Jakob Korherr Assignee: Jakob Korherr As we currently only have normal JUnit tests for automated testing in MyFaces Core, it would be really great to have a way to test MyFaces Core automatically in a real webapp at build time with maven. Of course, we currently have the test-webapp, but we still have to check each page manually here, if we want to test everything, which is long-winded. In addition, it would be cool if we could use this also for testing of MyFaces extensions against MyFaces Core and Mojarra. To accomplish something like that we could use test frameworks like e.g. Canoo WebTest or HttpUnit + Jetty or something similar. Basically anything that works with jetty in maven, but can also be used with other servers like tomcat or glassfish, would be ok here. I also want to mention JSFUnit here, although we won't be able to use it since it is LGPL licensed. The two most important things about this module would be 1) that everything has to work totally automated within maven and without a browser (so I wouldn't consider selenium as an option) and 2) a fluent and easy API to write those tests (otherwise no one would use it). This would help us enormously in ensuring and improving the quality of MyFaces Core and its extensions by getting a far bigger test coverage and more possibilities to test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Jakob Korherr jakob.korh...@gmail.com Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906724#action_12906724 ] Matthias Weßendorf commented on TRINIDAD-1906: -- One solution could be to have a custom taghandler for f:ajax, which hooks up the correct Trinidad logic. However the same issue would be still present, if page authors call directly jsf.ajax.request(); (or 3rd party libraries) Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
+1 Try to add my 5 or so improvements this weekend. Regards Rudy. On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Jakob Korherr jakob.korh...@gmail.com Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
submit and ajax request will not be queued together
Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[
https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906769#action_12906769
]
Matthias Weßendorf commented on TRINIDAD-1906:
--
For that we need to replace the request() function, provided by JSF
E.g. something like:
_replaceJsfAjaxFunctions = function()
{
if (this._jsfAjaxInit || typeof this._window.jsf == undefined ||
typeof this._window.jsf.ajax == undefined)
{
return;
}
var a = jsf.ajax;
a._origRequest = a.request;
a._origAddOnEvent = a.addOnEvent;
a._origAddOnError = a.addOnError;
a.request = this.createCallback(_ourStuff_);
a.addOnEvent = this.createCallback(_ourStuff_);
a.addOnError = this.createCallback(_ourStuff_);
this._jsfAjaxInit = true;
}
Client Validation igonred with f:ajax tag
---
Key: TRINIDAD-1906
URL: https://issues.apache.org/jira/browse/TRINIDAD-1906
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0.3-core
Reporter: Matthias Weßendorf
Have a form like:
...
tr:form
tr:panelFormLayout
tr:inputText id=ajax label=Field 1:
f:ajax event=change /
/tr:inputText
tr:inputText id=ppr label=Field 2: required=true
/tr:inputText
/tr:panelFormLayout
/tr:form
...
Go to field1, type and TAB out:
= An ajax request is queued and send down to the server
In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that
Field 2 is required
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: submit and ajax request will not be queued together
Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
Re: submit and ajax request will not be queued together
Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
Re: submit and ajax request will not be queued together
I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
Re: submit and ajax request will not be queued together
txs Werner, I'll tinker together a small standalone test app until this evening. The problem seem that we FIRST call the ajax request (opening a small javascript yes/no dialog) and THEN the user hits the commandButton. You can try this by invoking a ajax method which calls a sleep(3) and hit the button in the meantime. LieGrue, strub --- On Tue, 9/7/10, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 12:06 PM I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
[jira] Updated: (MYFACES-2908) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing
[ https://issues.apache.org/jira/browse/MYFACES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini updated MYFACES-2908: - Status: Resolved (was: Patch Available) Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing -- Key: MYFACES-2908 URL: https://issues.apache.org/jira/browse/MYFACES-2908 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2908-patch.txt Looks like when MYFACES-2854 was committed, there were two issues it caused where we break spec compliance. Both are around behavior that If the component ID of componentResource matches the the ID of a resource that has allready been added, remove the old resource. The first is that it looks like the else if (componentId != null) statement is in the wrong place. If a UIComponent is added with the same ID as an existing component, we'll never get to this check since we'll be false on the isInView() check. This will cause duplicate ID exceptions to be thrown if multiple objects with the same ID are added. This is easily resolved by moving the else if to kick in whenever isInView() is false. The second issue, and the more important since this is breaking a TCK test, is that since we were only comparing to the parent's ID to the location prefix, we weren't handling the case where the same object gets added a second time after updating the target. This can be resolved by changing if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().startsWith(JAVAX_FACES_LOCATION_PREFIX)) ... to if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().equals(JAVAX_FACES_LOCATION_PREFIX + target)) I'll attach a patch for review while I wait for our CTS team to try the change out. I probably wont' be able to commit until after the US Labor Day holiday since I'm away Friday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: submit and ajax request will not be queued together
Hi Mark, A standard form submit will always go through whether an AJAX request is running or not. There is no queueing of no AJAX submits. You may consider disabling the button until the AJAX request is successfull. Best regards, Ganesh Mark Struberg schrieb: txs Werner, I'll tinker together a small standalone test app until this evening. The problem seem that we FIRST call the ajax request (opening a small javascript yes/no dialog) and THEN the user hits the commandButton. You can try this by invoking a ajax method which calls a sleep(3) and hit the button in the meantime. LieGrue, strub --- On Tue, 9/7/10, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 12:06 PM I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner -- There are two kinds of people in the world, those who believe there are two kinds of people and those who don't. — Robert Benchley
Re: submit and ajax request will not be queued together
I dont think they have a form submit issue here, that has been resolved a while ago, but I cannot see in my code how a concurrent submit can happen either because a lock monitor is set once the request is set to send, which then blocks and reroutes subsequent requests until the issued request is done. After that the queue is notified to dequeue the next hanging request for the ajax processing. Basically a sleep 3 is just what I am simulating on my testcase differently here I issue a first request, the request then hangs on the server for a period of time and then I issue subsequent requests. The way I understand the javascript model is that nothing should be triggered from the sleep timer until the issuing request function has issued the send and returned, by that time the sleep in Marks case triggers but then the lockstate already is set and the issued ajax request should go straight into the queue. So it will be really interestint to see what happens here, not that I really can say that we might have a fault in our code, but without a real testingcase where I can reproduce the issue I have a hard time to find out what happens. Am 07.09.10 15:29, schrieb Ganesh: Hi Mark, A standard form submit will always go through whether an AJAX request is running or not. There is no queueing of no AJAX submits. You may consider disabling the button until the AJAX request is successfull. Best regards, Ganesh Mark Struberg schrieb: txs Werner, I'll tinker together a small standalone test app until this evening. The problem seem that we FIRST call the ajax request (opening a small javascript yes/no dialog) and THEN the user hits the commandButton. You can try this by invoking a ajax method which calls a sleep(3) and hit the button in the meantime. LieGrue, strub --- On Tue, 9/7/10, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 12:06 PM I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
[jira] Reopened: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz reopened MYFACES-2904: -- Ok sorry for the delay, but I was bound by customer projects, I reevaluated the code, there were bugs in the ie part of things, I cleaned up the code it should work now, I will commit my working codebase, but the table part needs further testing on my side. javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: submit and ajax request will not be queued together
Werner do you call the sleep in javascript? I meant to sleep(3s) in the java code on the server. LieGrue, strub --- On Tue, 9/7/10, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 1:43 PM I dont think they have a form submit issue here, that has been resolved a while ago, but I cannot see in my code how a concurrent submit can happen either because a lock monitor is set once the request is set to send, which then blocks and reroutes subsequent requests until the issued request is done. After that the queue is notified to dequeue the next hanging request for the ajax processing. Basically a sleep 3 is just what I am simulating on my testcase differently here I issue a first request, the request then hangs on the server for a period of time and then I issue subsequent requests. The way I understand the javascript model is that nothing should be triggered from the sleep timer until the issuing request function has issued the send and returned, by that time the sleep in Marks case triggers but then the lockstate already is set and the issued ajax request should go straight into the queue. So it will be really interestint to see what happens here, not that I really can say that we might have a fault in our code, but without a real testingcase where I can reproduce the issue I have a hard time to find out what happens. Am 07.09.10 15:29, schrieb Ganesh: Hi Mark, A standard form submit will always go through whether an AJAX request is running or not. There is no queueing of no AJAX submits. You may consider disabling the button until the AJAX request is successfull. Best regards, Ganesh Mark Struberg schrieb: txs Werner, I'll tinker together a small standalone test app until this evening. The problem seem that we FIRST call the ajax request (opening a small javascript yes/no dialog) and THEN the user hits the commandButton. You can try this by invoking a ajax method which calls a sleep(3) and hit the button in the meantime. LieGrue, strub --- On Tue, 9/7/10, Werner Punz werner.p...@gmail.com wrote: From: Werner Punz werner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 12:06 PM I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
Re: [VOTE] Trinidad core: 2.0.0 beta1
Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[VOTE] Trinidad core: 2.0.0 beta1
+1 On Tue, Sep 7, 2010 at 4:39 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (MYFACES-2904) javascript _Dom._outerHtml does not handle table items (tr, tbody. ...)
[ https://issues.apache.org/jira/browse/MYFACES-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2904. -- Resolution: Fixed ok I gave the fixup code now a testrun, leos code with my fixes now work perfectly. The Sieve test does not show any problems. Seems like the fix works. Also table element replacement now seems to work like a charm. Thanks Leo for providing the fix. javascript _Dom._outerHtml does not handle table items (tr, tbody. ...) --- Key: MYFACES-2904 URL: https://issues.apache.org/jira/browse/MYFACES-2904 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2904-1.patch Checking some stuff in tomahawk, I found that when a fragment starts with tr or some tag that should be used inside table are trimmed when are replaced on an ajax request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[COMMUNITY] MyFaces += Martin Kočí
The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2912) Wrong JNDI Name for Method Resource Injections
Wrong JNDI Name for Method Resource Injections -- Key: MYFACES-2912 URL: https://issues.apache.org/jira/browse/MYFACES-2912 Project: MyFaces Core Issue Type: Bug Reporter: Gurkan Erdogdu Attachments: patch.txt Method based JNDI env. injections not worked correctly. Patch is attached. See Java EE 6 specification section, EE. 5.2.5 Annotations and Injections. Patch is provided that solves problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: submit and ajax request will not be queued together
I actually call sleep 3000 on the server in a servlet which is a protocol simulator and then issue subsequent requests. here is an image of what I am getting: http://people.apache.org/~werpu/images/delayscreenie.jpeg as you can see clear 3 second delays between the requests! Werner Am 07.09.10 16:15, schrieb Mark Struberg: Werner do you call the sleep in javascript? I meant to sleep(3s) in the java code on the server. LieGrue, strub --- On Tue, 9/7/10, Werner Punzwerner.p...@gmail.com wrote: From: Werner Punzwerner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 1:43 PM I dont think they have a form submit issue here, that has been resolved a while ago, but I cannot see in my code how a concurrent submit can happen either because a lock monitor is set once the request is set to send, which then blocks and reroutes subsequent requests until the issued request is done. After that the queue is notified to dequeue the next hanging request for the ajax processing. Basically a sleep 3 is just what I am simulating on my testcase differently here I issue a first request, the request then hangs on the server for a period of time and then I issue subsequent requests. The way I understand the javascript model is that nothing should be triggered from the sleep timer until the issuing request function has issued the send and returned, by that time the sleep in Marks case triggers but then the lockstate already is set and the issued ajax request should go straight into the queue. So it will be really interestint to see what happens here, not that I really can say that we might have a fault in our code, but without a real testingcase where I can reproduce the issue I have a hard time to find out what happens. Am 07.09.10 15:29, schrieb Ganesh: Hi Mark, A standard form submit will always go through whether an AJAX request is running or not. There is no queueing of no AJAX submits. You may consider disabling the button until the AJAX request is successfull. Best regards, Ganesh Mark Struberg schrieb: txs Werner, I'll tinker together a small standalone test app until this evening. The problem seem that we FIRST call the ajax request (opening a small javascript yes/no dialog) and THEN the user hits the commandButton. You can try this by invoking a ajax method which calls a sleep(3) and hit the button in the meantime. LieGrue, strub --- On Tue, 9/7/10, Werner Punzwerner.p...@gmail.com wrote: From: Werner Punzwerner.p...@gmail.com Subject: Re: submit and ajax request will not be queued together To: dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 12:06 PM I also checked the queue testcodes on my side. I have a testcase where a server servlet delays the response for three seconds, but it triggers directly jsf.ajax.request. That is on the latest codebase. What happens is following if I press the button multiple times, the requests are issued exactly after the delay which means the requests are definitely queued in while the original request is running. Are you using the jsf.ajax.request in conjunction with a layer which sits on top of it and maybe bypasses the core code or rolls its own ajax send scripts? Werner Am 07.09.10 13:55, schrieb Werner Punz: Ok Mark I checked the code there should be no two requests being sent issue there, the code definitely enqueues while a request is running, and dequeues once the request has done its work. But I do not want to rule out a bug here on code level, but can you send me a demo app so that I can have a look. Btw. which version of the codebase are you on? lG Werner Am 07.09.10 13:42, schrieb Werner Punz: Am 07.09.10 13:26, schrieb Mark Struberg: Hi! We have a page which renders a confirmation dialogue area with f:ajax and this confirmation dialogue has a h:commandButton. Since our view restoration may take a bit it happens that the user might click fast enough on the commandbutton while the ajax request is still on the server. Thus we might have 2 parallel requests on the same @ViewScoped bean. This is even more troublesome if we use CDI @ConversationScoped beans. We looked at the jsf.js and it seems that although concurrent f:ajax requests get queued the submit via the commandButton hits the server unqueued. Is this behaviour in sync with the spec? There is a workaround to also only use f:ajax with commandButtons, but since I have to use this all the times it could be easier to queue submits also. LieGrue, strub I will investigate it the first request should get through unqueued the second one has to go into the queue and wait while the first one is executing that is the expected behavior, let me check if we have a queuing error there. There should be no request issued against the server while another one currently is on the server. Werner
Re: [COMMUNITY] MyFaces += Martin Kočí
Welcome Martin ! On Tue, Sep 7, 2010 at 7:50 AM, Matthias Wessendorf mat...@apache.orgwrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [COMMUNITY] MyFaces += Martin Kočí
welcome! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad plugins: 2.0.2 release
+1 build fine from src.tar.gz + passes rat + sha1 + md5 LieGrue, strub --- On Tue, 9/7/10, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf mat...@apache.org Subject: [VOTE] Trinidad plugins: 2.0.2 release To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 7:23 AM Hi, I was running the needed tasks to get the 2.0.2 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.2 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad core: 2.0.0 beta1
+1 builds fine from src.tar.gz + passes rat (only minor miss is maven-faces-plugin/Global.xml and a few xmls in the examples) + sha1 ok + md5 ok LieGrue, strub --- On Tue, 9/7/10, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf mat...@apache.org Subject: [VOTE] Trinidad core: 2.0.0 beta1 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, September 7, 2010, 2:42 PM +1 On Tue, Sep 7, 2010 at 4:39 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad core: 2.0.0 beta1
+1 -- Blake Sullivan On 9/7/10 7:39 AM, Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/
Re: [VOTE] Trinidad plugins: 2.0.2 release
+1 -- Blake Sullivan On 9/7/10 12:23 AM, Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 2.0.2 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.2 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/
Re: [COMMUNITY] MyFaces += Martin Kočí
Congratulations! -- Blake Sullivan On 9/7/10 8:26 AM, Gerhard wrote: welcome! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1905) Problem with the JMeter HTTP Proxy
[ https://issues.apache.org/jira/browse/TRINIDAD-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906866#action_12906866 ] Blake Sullivan commented on TRINIDAD-1905: -- The code appears to be expecting that the only header that will appear in each of the subsections is the content-type header. This is clearly wrong. From the RFC: A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the encapsulation is plain US-ASCII text. The only header fields that have defined meaning for body parts are those the names of which begin with Content-. All other header fields are generally to be ignored in body parts. Although they should generally be retained in mail processing, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but should not be depended on. X- fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways. The code will thus have to check all of the headers until it gets to the extra newline separating the header block Problem with the JMeter HTTP Proxy -- Key: TRINIDAD-1905 URL: https://issues.apache.org/jira/browse/TRINIDAD-1905 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core , 2.0.0-alpha-2 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf When running upload stress-tests with JMEter, there is a bug in Trinidad, as noticed here: http://markmail.org/message/p624zgpd7h2klleg Stack: org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest GRAVE: java.io.IOException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:208) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:119) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:523) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:209) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:142) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2908) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing
[ https://issues.apache.org/jira/browse/MYFACES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-2908: - The code that check for a duplicate component is on the right place. It seems the previous algorithm takes into consideration facelets added components but not programatically added ones. So the fix is correct if a component is added programatically but makes facelets added component (h:outputScript, h:outputStylesheet). Right now, we have tag handlers for h:outputScript and h:outputStylesheet that prevents double addition, but if some user create a tag with a similar behavior it will fail. UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing -- Key: MYFACES-2908 URL: https://issues.apache.org/jira/browse/MYFACES-2908 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2908-patch.txt Looks like when MYFACES-2854 was committed, there were two issues it caused where we break spec compliance. Both are around behavior that If the component ID of componentResource matches the the ID of a resource that has allready been added, remove the old resource. The first is that it looks like the else if (componentId != null) statement is in the wrong place. If a UIComponent is added with the same ID as an existing component, we'll never get to this check since we'll be false on the isInView() check. This will cause duplicate ID exceptions to be thrown if multiple objects with the same ID are added. This is easily resolved by moving the else if to kick in whenever isInView() is false. The second issue, and the more important since this is breaking a TCK test, is that since we were only comparing to the parent's ID to the location prefix, we weren't handling the case where the same object gets added a second time after updating the target. This can be resolved by changing if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().startsWith(JAVAX_FACES_LOCATION_PREFIX)) ... to if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().equals(JAVAX_FACES_LOCATION_PREFIX + target)) I'll attach a patch for review while I wait for our CTS team to try the change out. I probably wont' be able to commit until after the US Labor Day holiday since I'm away Friday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2908) UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing
[ https://issues.apache.org/jira/browse/MYFACES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2908. - Resolution: Fixed UIViewRoot.addComponentResource() adding multiple components with same ID instead of replacing -- Key: MYFACES-2908 URL: https://issues.apache.org/jira/browse/MYFACES-2908 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2908-patch.txt Looks like when MYFACES-2854 was committed, there were two issues it caused where we break spec compliance. Both are around behavior that If the component ID of componentResource matches the the ID of a resource that has allready been added, remove the old resource. The first is that it looks like the else if (componentId != null) statement is in the wrong place. If a UIComponent is added with the same ID as an existing component, we'll never get to this check since we'll be false on the isInView() check. This will cause duplicate ID exceptions to be thrown if multiple objects with the same ID are added. This is easily resolved by moving the else if to kick in whenever isInView() is false. The second issue, and the more important since this is breaking a TCK test, is that since we were only comparing to the parent's ID to the location prefix, we weren't handling the case where the same object gets added a second time after updating the target. This can be resolved by changing if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().startsWith(JAVAX_FACES_LOCATION_PREFIX)) ... to if (componentResource.getParent() != null componentResource.getParent().getId() != null componentResource.getParent().getId().equals(JAVAX_FACES_LOCATION_PREFIX + target)) I'll attach a patch for review while I wait for our CTS team to try the change out. I probably wont' be able to commit until after the US Labor Day holiday since I'm away Friday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release Bridge Master 4
Please vote on the proposed release of MyFaces Portlet Bridge Master version 4. This version of the bridge master uses version 9 of the myfaces plugin to allow artifacts to be published to repository.apache.org as per the Apache instructions [1]. The bridge master artifacts have been staged to the Nexus repository at [2]. Please note: This is a minor change so we're proposing the vote is open for 48 hours rather than the usual 72. [ ] +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.. [1]: http://www.apache.org/dev/publishing-maven-artifacts.html [2]: https://repository.apache.org/content/repositories/orgapachemyfaces-035/
Re: [VOTE] Release Bridge Master 4
+1 for the vote +1 for only 48 hours On Tue, Sep 7, 2010 at 10:42 AM, Scott O'Bryan darkar...@gmail.com wrote: Please vote on the proposed release of MyFaces Portlet Bridge Master version 4. This version of the bridge master uses version 9 of the myfaces plugin to allow artifacts to be published to repository.apache.org as per the Apache instructions [1]. The bridge master artifacts have been staged to the Nexus repository at [2]. Please note: This is a minor change so we're proposing the vote is open for 48 hours rather than the usual 72. [ ] +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.. [1]: http://www.apache.org/dev/publishing-maven-artifacts.html [2]: https://repository.apache.org/content/repositories/orgapachemyfaces-035/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [VOTE] Trinidad core: 2.0.0 beta1
+1 On Tue, Sep 7, 2010 at 9:18 AM, Blake Sullivan blake.sulli...@oracle.comwrote: +1 -- Blake Sullivan On 9/7/10 7:39 AM, Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [VOTE] Trinidad plugins: 2.0.2 release
+1 On Tue, Sep 7, 2010 at 9:18 AM, Blake Sullivan blake.sulli...@oracle.comwrote: +1 -- Blake Sullivan On 9/7/10 12:23 AM, Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 2.0.2 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.2 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/ /url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [COMMUNITY] MyFaces += Martin Kočí
Welcome, Martin! Regards, Jakob 2010/9/7, Blake Sullivan blake.sulli...@oracle.com: Congratulations! -- Blake Sullivan On 9/7/10 8:26 AM, Gerhard wrote: welcome! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [COMMUNITY] MyFaces += Martin Kočí
Welcome! Leonardo 2010/9/7 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906906#action_12906906 ] Andrew Robinson commented on TRINIDAD-1906: --- I would vote that this is not a bug, and should not be fixed for Trinidad 2. f:ajax is a JSF tag, not a Trinidad tag and we should not have to support it with respect to client validation in JSF 2.0 for the following reasons. I would say that we should wait for JSF 2.1 where, hopefully, the EG puts in API hooks to allow users to perform client side validation during a JSF ajax request. It was commented for JSF 2.0 that such a hook should exist and the EG dropped the ball on it and it was not included into the spec. A work around is to use the Trinidad APIs to submit the request. I would say that we could provide a tr:ajax that would be supported or we could hijack the f:ajax tag handler, although I would hesitate to do that as it would make Trinidad not play nice with other JSF libraries. I do not feel that replacing the JSF request function is a good choice as we ought not to be messing with the JSF internal code if we can possibly help it. Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Trinidad core: 2.0.0 beta1
-0.5 It appears that the fix for TRINIDAD-1902 has some drawbacks that cause some severe errors. The PseudoFacesContext.getViewRoot() throws an unsupported operation exception when called. It should probably just return null instead as that is what is expected when the view has not be created/restored yet. I would say that this should be fixed before a release. -Andrew On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906911#action_12906911 ] Matthias Weßendorf commented on TRINIDAD-1906: -- if we decorate f:ajax (or provide a tr:ajax) there is still the issue with vanilla JS call (jsf.ajax.request()). Andrew, do you know if there is a ticket for the missing hooks? I am also not really looking to add an tr:ajax and yes, replacing the request() function is odd, but with that, folks can use jsf.ajax.request() on a natural base, and they don't notice any surprise. But sure... there is a downside for doing so. Clearly: the JS API has limitations, and the real fix is that there should be hooks. I will keep this ticket open, does not hurt to have one more open item, IMO :) Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906913#action_12906913 ] Andrew Robinson commented on TRINIDAD-1906: --- Note that I sent a question/bug to the RI team that the onEvent should be documented on how it handles JS errors. If this were allowed, we could simply perform client side validation during the begin event of the JSF ajax request and if validation fails, throw an error. The problem with this approach, is that this assumes that the user wants client side validation to be run before a JSF ajax request. Because JSF ajax requests do not have to be form submissions, and may only be JSF based ajax get requests, the developer may want to still go back to the server if there is invalid data (to look up valid values to show the user for example). Forcing client validation to be run for all JSF ajax requests could be viewed as a severe blocking bug if the user wanted to do so. Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Trinidad core: 2.0.0 beta1
Ah, ok I see. Thanks for pointing it out! Jakob, can you take over on your fix for Trinidad-1902 ? -Matthias On Tue, Sep 7, 2010 at 8:00 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: -0.5 It appears that the fix for TRINIDAD-1902 has some drawbacks that cause some severe errors. The PseudoFacesContext.getViewRoot() throws an unsupported operation exception when called. It should probably just return null instead as that is what is expected when the view has not be created/restored yet. I would say that this should be fixed before a release. -Andrew On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release Bridge Master 4
Scott, +1 on the release. We had done lazy consensus votes (see [1]) on poms in the past. So feel free to vote and move on :-) -Matthias [1] http://apache.org/foundation/how-it-works.html#management On Tue, Sep 7, 2010 at 7:49 PM, Grant Smith work.gr...@gmail.com wrote: +1 for the vote +1 for only 48 hours On Tue, Sep 7, 2010 at 10:42 AM, Scott O'Bryan darkar...@gmail.com wrote: Please vote on the proposed release of MyFaces Portlet Bridge Master version 4. This version of the bridge master uses version 9 of the myfaces plugin to allow artifacts to be published to repository.apache.org as per the Apache instructions [1]. The bridge master artifacts have been staged to the Nexus repository at [2]. Please note: This is a minor change so we're proposing the vote is open for 48 hours rather than the usual 72. [ ] +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.. [1]: http://www.apache.org/dev/publishing-maven-artifacts.html [2]: https://repository.apache.org/content/repositories/orgapachemyfaces-035/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [COMMUNITY] MyFaces += Martin Kočí
Martin, Congratulations! Great to have you on board. Max On 9/7/2010 10:50 AM, Matthias Wessendorf wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906916#action_12906916 ] Matthias Weßendorf commented on TRINIDAD-1906: -- as we now speak about client-side validation. Was there something promised for JSF 2.1 ? (I don't really follow the open EG list) Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1906) Client Validation igonred with f:ajax tag
[ https://issues.apache.org/jira/browse/TRINIDAD-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12906922#action_12906922 ] Werner Punz commented on TRINIDAD-1906: --- Actually from my knowledge the best bet on what is going into 2.1 is to check the bugtracker. There already is some stuff postponed for 2.2 due to the tight schedule they have for 2.1. So the originally planned 2.1 probably will be 2-3 subsequent releases given the new schedule they have. My fileupload stuff for instance already was postponed to 2.2 because they would not make it in time anymore for mojarra. Client Validation igonred with f:ajax tag --- Key: TRINIDAD-1906 URL: https://issues.apache.org/jira/browse/TRINIDAD-1906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Matthias Weßendorf Have a form like: ... tr:form tr:panelFormLayout tr:inputText id=ajax label=Field 1: f:ajax event=change / /tr:inputText tr:inputText id=ppr label=Field 2: required=true /tr:inputText /tr:panelFormLayout /tr:form ... Go to field1, type and TAB out: = An ajax request is queued and send down to the server In Trinidad (with autosubmit, instead of f:ajax) you'd see a warning that Field 2 is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Trinidad core: 1.2.14
Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad core: 1.2.14
+1 sent from my Android phone On Sep 7, 2010 8:27 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad core: 1.2.14
+1 On 9/7/10 11:30 AM, Matthias Wessendorf wrote: +1 sent from my Android phone On Sep 7, 2010 8:27 PM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ http://people.apache.org/%7Ematzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Trinidad core: 1.2.14
+1 Regards, Udo Am 07.09.10 20:30, schrieb Matthias Wessendorf: +1 sent from my Android phone On Sep 7, 2010 8:27 PM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ http://people.apache.org/%7Ematzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [COMMUNITY] MyFaces += Martin Kočí
Hi, it's an honour for me, thanks for inviting me to this great community. Just for curiosity I found this: https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more than four years ago - time runs so fast! That reminds me: I started with JSF 0.4 EA - do you remember h:command_button tag with underscore :) ? Over time I participated in development of more than five large systems with JSF based GUI and experiences I'll share with you here. Thanks, Martin Kočí Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
Re: [VOTE] Trinidad core: 1.2.14
+1 On Tue, Sep 7, 2010 at 12:29 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Regards, Udo Am 07.09.10 20:30, schrieb Matthias Wessendorf: +1 sent from my Android phone On Sep 7, 2010 8:27 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/http://people.apache.org/%7Ematzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] Created: (TRINIDAD-1907) Trinidad-1902 breaks any code that checks to see if a view root is set on the facet context
Trinidad-1902 breaks any code that checks to see if a view root is set on the facet context --- Key: TRINIDAD-1907 URL: https://issues.apache.org/jira/browse/TRINIDAD-1907 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Blocker the PseudoFacesContext that was added to Trinidad is causing a large regression in our product. We have code that is checking to see if the view root is set in order to determine the locale. Since the new faces context class throws an exception, the code now fails. This method should return null instead of throwing an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Trinidad core: 2.0.0 beta1
Please include the fix: https://issues.apache.org/jira/browse/TRINIDAD-1907 On Tue, Sep 7, 2010 at 12:09 PM, Matthias Wessendorf mat...@apache.org wrote: Ah, ok I see. Thanks for pointing it out! Jakob, can you take over on your fix for Trinidad-1902 ? -Matthias On Tue, Sep 7, 2010 at 8:00 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: -0.5 It appears that the fix for TRINIDAD-1902 has some drawbacks that cause some severe errors. The PseudoFacesContext.getViewRoot() throws an unsupported operation exception when called. It should probably just return null instead as that is what is expected when the view has not be created/restored yet. I would say that this should be fixed before a release. -Andrew On Tue, Sep 7, 2010 at 8:39 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the first beta release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.0-beta1 artifacts and vote. Main diff between the other alphas is that ajax support has been added. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (TRINIDAD-1907) Trinidad-1902 breaks any code that checks to see if a view root is set on the facet context
[ https://issues.apache.org/jira/browse/TRINIDAD-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1907. --- Fix Version/s: 2.0.0.3-core Resolution: Fixed added sensible method returns for some of the functions of the PseudoFacesContext methods that should not be throwing exceptions Trinidad-1902 breaks any code that checks to see if a view root is set on the facet context --- Key: TRINIDAD-1907 URL: https://issues.apache.org/jira/browse/TRINIDAD-1907 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Blocker Fix For: 2.0.0.3-core the PseudoFacesContext that was added to Trinidad is causing a large regression in our product. We have code that is checking to see if the view root is set in order to determine the locale. Since the new faces context class throws an exception, the code now fails. This method should return null instead of throwing an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2913) Params inside command sent by ajax are not handled correctly
Params inside command sent by ajax are not handled correctly Key: MYFACES-2913 URL: https://issues.apache.org/jira/browse/MYFACES-2913 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe We have two small bugs that prevent params work correctly on ajax case when jsf.chain is rendered. In theory, ClientBehaviorContext.Parameter should contains the values without quotes and all parameter names and values should be qouted, but on HtmlAjaxBehaviorRenderer, so the code escaping it could handle correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2913) Params inside command sent by ajax are not handled correctly
[ https://issues.apache.org/jira/browse/MYFACES-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2913. - Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed Params inside command sent by ajax are not handled correctly Key: MYFACES-2913 URL: https://issues.apache.org/jira/browse/MYFACES-2913 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT We have two small bugs that prevent params work correctly on ajax case when jsf.chain is rendered. In theory, ClientBehaviorContext.Parameter should contains the values without quotes and all parameter names and values should be qouted, but on HtmlAjaxBehaviorRenderer, so the code escaping it could handle correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1548) Allow t:dataScroller to be Ajaxified using f:ajax
Allow t:dataScroller to be Ajaxified using f:ajax - Key: TOMAHAWK-1548 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1548 Project: MyFaces Tomahawk Issue Type: Improvement Components: Data Scroller Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe After thinking a lot about it, to make it possible we need to do some things: - If no facet or paginator is rendered, render a div and the id, so when ajax occur it could be replaced. - If a facet or paginator is rendered, if an id is set render it. - Add click, dblclick and action client events and copy them for all facets and paginator links. - Add action as default event name. In this way, not we can add f:ajax tag inside datatable to tell when a link is click, which elements should be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1548) Allow t:dataScroller to be Ajaxified using f:ajax
[ https://issues.apache.org/jira/browse/TOMAHAWK-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1548. -- Fix Version/s: 1.1.10-SNAPSHOT Resolution: Fixed Allow t:dataScroller to be Ajaxified using f:ajax - Key: TOMAHAWK-1548 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1548 Project: MyFaces Tomahawk Issue Type: Improvement Components: Data Scroller Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT After thinking a lot about it, to make it possible we need to do some things: - If no facet or paginator is rendered, render a div and the id, so when ajax occur it could be replaced. - If a facet or paginator is rendered, if an id is set render it. - Add click, dblclick and action client events and copy them for all facets and paginator links. - Add action as default event name. In this way, not we can add f:ajax tag inside datatable to tell when a link is click, which elements should be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
+1 I'll start to work on some test for ajax using that stuff. regards, Leonardo 2010/9/7 Rudy De Busscher rdebussc...@gmail.com +1 Try to add my 5 or so improvements this weekend. Regards Rudy. On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Jakob Korherr jakob.korh...@gmail.com Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
Hi How that stuff work? I thought that it was only necessary to run it using maven goals or something like that, but for my surprise it is not. In the documentation left there are no instructions about how to do a simple test helloworld app. regards, Leonardo Uribe 2010/9/7 Leonardo Uribe lu4...@gmail.com +1 I'll start to work on some test for ajax using that stuff. regards, Leonardo 2010/9/7 Rudy De Busscher rdebussc...@gmail.com +1 Try to add my 5 or so improvements this weekend. Regards Rudy. On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Jakob Korherr jakob.korh...@gmail.com Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] [GSoC] Automated webapp test framework integration
Hi Ok, it seems it is not tied to maven lifecycle, but runs with eclipse. It says it requires java 1.5 but it is not true, it requires java 1.6. regards, Leonardo 2010/9/7 Leonardo Uribe lu4...@gmail.com Hi How that stuff work? I thought that it was only necessary to run it using maven goals or something like that, but for my surprise it is not. In the documentation left there are no instructions about how to do a simple test helloworld app. regards, Leonardo Uribe 2010/9/7 Leonardo Uribe lu4...@gmail.com +1 I'll start to work on some test for ajax using that stuff. regards, Leonardo 2010/9/7 Rudy De Busscher rdebussc...@gmail.com +1 Try to add my 5 or so improvements this weekend. Regards Rudy. On 7 September 2010 11:23, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/7 Jakob Korherr jakob.korh...@gmail.com Hi, I just committed the webapptest project into the gsoc folder. Now we can start to improve it in order to be able to do a first alpha release. In addition I'd like to create a webapptest component for the MYFACESTEST project in the JIRA. Any objections or better ideas? Regards, Jakob 2010/9/6 Jakob Korherr jakob.korh...@gmail.com: Hi, Thinking about it, it may be better at the moment to commit it into the gsoc folder and enhance it first. Then when we think we can do the first alpha release, we can move it into a different folder. However I really think that it should be separated from MyFaces-test, since MyFaces-test is a mocking framework and webapp-test is kind of an integration testing framework. But we can deal with this question later. Regards, Jakob 2010/9/4 Leonardo Uribe lu4...@gmail.com Hi No objections for my side, but could you be more explicit about what you gonna do? Do you want to include it as a separate module for myfaces-test (note this requires an official vote)? or maybe create a branch on myfaces-test so we can enhance it and when it is ready, do some alpha/beta releases?. regards, Leonardo Uribe 2010/9/4 Jakob Korherr jakob.korh...@gmail.com Hi, If no objections I'll start the integration today into myfaces/test/webapptest. Regards, Jakob 2010/8/23 Jakob Korherr jakob.korh...@gmail.com Hi, Since GSoC is over, we can now integrate the code into our codebase. The code currently lives in a google code project [1]. Because of the fact that this is a test framework, I would really like to put it into the test folder rather then creating a new (myfaces-)top-level entry. However I do not want to integrate it into the current MyFaces test framework (that currently lives in the test folder), because this is a completely different thing and IMO we have to be able to do separate releases of those two. In addition I would like to create a new project in the JIRA for the automated webapp tests framework. Something like WEBAPPTEST. Suggestions are welcome! What do you think? Any objections, thoughts, ideas? Thanks for looking into this! Regards, Jakob [1] http://code.google.com/p/gsoc2010-automated-myfaces-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
