[JBoss JIRA] (RF-13678) Render @all does not work for nested a4j:region in collapsibleSubTable
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13678?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13678:
-------------------------------
Original Estimate: 2 hours
Remaining Estimate: 2 hours
> Render @all does not work for nested a4j:region in collapsibleSubTable
> ----------------------------------------------------------------------
>
> Key: RF-13678
> URL: https://issues.jboss.org/browse/RF-13678
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Labels: regression
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Suppose nested {{regions}} in a {{collapsibleSubTable}}.
> Those regions are not updated when a {{commandButton}} with {{render}} attribute set to {{@all}} is submitted.
> IMHO it is somehow connected with RF-13677, however, this issue occurs only with combination of {{regions}} and {{collapsibleSubTable}}, other iteration components works in this matter.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13660:
-------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
> RichFaces 4.5 integration tests - error after test execution
> ------------------------------------------------------------
>
> Key: RF-13660
> URL: https://issues.jboss.org/browse/RF-13660
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 4.5.0.Alpha2
> Environment: AS: Wildfly
> Browser: PhantomJS
> Reporter: Matej Novotny
> Assignee: Juraj Húska
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> This issue originated from RF-13591.
> There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/...].
> The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines.
> Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/...].
> The exception in server console is:
> {code}
> 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException
> at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final]
> at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13651) Integration tests failing in chrome
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13651?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13651:
-------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
> Integration tests failing in chrome
> -----------------------------------
>
> Key: RF-13651
> URL: https://issues.jboss.org/browse/RF-13651
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Reporter: Brian Leathem
> Assignee: Matej Novotny
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> The framework tests pass in phantomjs but some fail in chrome.
> Resolution of this issue involves running and stabilizing the tests in all supported browsers.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13707) Photoalbum: incorrect account details shown after creating a new one
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13707?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13707:
-------------------------------
Fix Version/s: 4.5-Tracking
> Photoalbum: incorrect account details shown after creating a new one
> --------------------------------------------------------------------
>
> Key: RF-13707
> URL: https://issues.jboss.org/browse/RF-13707
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: examples
> Affects Versions: 4.3.8
> Reporter: Juraj Húska
> Labels: photoalbum
> Fix For: 4.5-Tracking
>
>
> When user create a new account in Photoalbum application there are shown account details, which are incorrect:
> * missing login, first name, surname
> * wrong sex value (there is always female - I tried other than my photos as avatars, so the problem will be somewhere else :) )
> * missing Birthday and email
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13708) Photoalbum: refresh over index page throws error
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13708?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13708:
-------------------------------
Fix Version/s: 4.5-Tracking
> Photoalbum: refresh over index page throws error
> ------------------------------------------------
>
> Key: RF-13708
> URL: https://issues.jboss.org/browse/RF-13708
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: examples
> Affects Versions: 4.3.8
> Environment: container: JBoss EAP 6.3.0.ER8, other EAPS as well
> browsers: all
> Reporter: Juraj Húska
> Labels: photoalbum
> Fix For: 4.5-Tracking
>
>
> Refresh over index page of Photoalbum throws:
> {code}
> 14:31:05,563 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (http-/127.0.0.1:8080-5) javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view. : javax.faces.FacesException: Component ID overForm:PreDefinedTree:j_idt273 has already been found in the view.
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.28.redhat-3.jar:2.1.28.redhat-3]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.1.28.Final-redhat-1.jar:2.1.28.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-17.jar:7.4.0.Final-redhat-17]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.7.Final-redhat-1.jar:7.4.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> {code}
> After this error application cease to work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13706:
-------------------------------
Labels: waiting_on_user (was: )
> dequeued Ajax request not processed correctly if its source element has been updated
> ------------------------------------------------------------------------------------
>
> Key: RF-13706
> URL: https://issues.jboss.org/browse/RF-13706
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Reporter: Marcel Kolsteren
> Labels: waiting_on_user
> Attachments: queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip
>
>
> I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page.
> The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen.
> To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked:
> {noformat}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head/>
> <h:body>
> <form action="http://www.meandi.nl"/>
> <h:form>
> <a4j:commandLink action="#{richBean.waitThreeSeconds}" value="Click Me" render="@this"/>
> </h:form>
> </h:body>
> </html>
> {noformat}
> The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7.
> The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13706) dequeued Ajax request not processed correctly if its source element has been updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13706?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13706:
------------------------------------
RichFaces 4.3.7 is not compatible with JSF 2.2 / WildFly 8. Can you please verify that you observe this behaviour with a recent RichFaces 4.5 SNAPSHOT? (We'll have a RichFaces 4.5.0.Alpha3 release available in a couple of weeks).
> dequeued Ajax request not processed correctly if its source element has been updated
> ------------------------------------------------------------------------------------
>
> Key: RF-13706
> URL: https://issues.jboss.org/browse/RF-13706
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.7
> Reporter: Marcel Kolsteren
> Labels: waiting_on_user
> Attachments: queuetest.zip, richfaces-core-4.3.8-SNAPSHOT.patch.zip
>
>
> I found a problem in the RichFaces Ajax queuing mechanism, which can cause all JavaScript execution to stop, leaving the end user with an unresponsive page.
> The problem occurs when a request in the queue rerenders an area that includes the source element of the next request in the queue, but does not include the form of that source element. When the next request is fetched from the queue, JSF tries to find the correct form by climbing the DOM tree, starting at the source element of the event. However, because the source element has been rerendered, the path to its form is broken, and in that case JSF falls back to the first form of the page (see JavaScript function getForm that is called by jsf.ajax.request in jsf.js). If that form is not the form belonging to the rerendered version of the element, nasty things will happen.
> To illustrate this, I created a very simple Java EE 7 web application (see attached Maven project) and deployed it in WildFly 8.1.0.Final. It contains a page with one clickable link that rerenders itself when clicked:
> {noformat}
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head/>
> <h:body>
> <form action="http://www.meandi.nl"/>
> <h:form>
> <a4j:commandLink action="#{richBean.waitThreeSeconds}" value="Click Me" render="@this"/>
> </h:form>
> </h:body>
> </html>
> {noformat}
> The method "waitThreeSeconds" does nothing but waiting for three seconds. When the link is double clicked, you'll observe that the first click is handled correctly, but that the second click results in an Ajax request posted to the URL of the first form, leading to access denied errors (because of cross domain scripting). The used RichFaces version is 4.3.7.
> The problem can be fixed by changing the RichFaces JavaScript code, so that after completion of an Ajax request, stale elements are removed from the queue. I created a patch for RichFaces 4.3.7, and verified that it works (see attachment). Another solution strategy would be to try to find the new DOM element that corresponds to the stale source of the event, and fetch the form from that element. My thought was that removing the stale request would be better, because (1) it is kind of dangerous to process a user action on an element that has already been replaced and (2) the element might have been removed from the DOM tree by the previous rerender.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13704) Add link to rich:layout successor layout:layout
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13704?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13704.
--------------------------------
Labels: (was: richfaces)
Resolution: Rejected
As per the notes in the wiki article "Layout component is not official RichFaces component", and there is no plan to do so as the component is largely obsolete with JSF 2. You can ask the wiki article author [~Strannik] to provide a link in his wiki article.
> Add link to rich:layout successor layout:layout
> -----------------------------------------------
>
> Key: RF-13704
> URL: https://issues.jboss.org/browse/RF-13704
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: migration, third-party
> Reporter: Kalle Richter
> Priority: Trivial
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> The 3.3.x -> 4.x migration guide at https://community.jboss.org/wiki/RichFaces33-4xMigrationGuideUnleashed states that rich:layout has been replaced by/moved to the third-party project/namespace layout:layout. Where can it be found? Please add a link in the guide directly or an explanation if necessary as $SEARCH_ENGINE doesn't seem to find anything useful.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months