[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s... ]
Michael B commented on RF-13780:
--------------------------------
[~michpetrov] sorry for the wrong accusation then! - FireBug wraps the search trough all JS files...
So the problem can be worked around as we did with limitRender="true" fixed on rich:tree. But the original problem in the combination RF+Mojarra still remains if you omit to do this on every AJAX-request. This has the downside, that if you actually want to have some (valid and visible) components being re-rendered on an AJAX request without specifically adding those IDs to the rendered-attribute everywhere throughout the application, you can't do it anymore. As I mentioned, that leads to other problems...
The source of the problem being located in jsf.js means that this is originally bad handling by Mojarra?! - or is it just something that only happends because RF introduces the possibility of some components being automatically re-rendered after AJAX-Requests (like rich:message/s, a4j:outputPanel etc.)?
Will you be looking into the main issue as well? - maybe in cooperation with the guys from Mojarra? - or do we have to file a bug report at Mojarra - which would mean back to square one...
> Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
> ---------------------------------------------------------------------------
>
> Key: RF-13780
> URL: https://issues.jboss.org/browse/RF-13780
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component, component-tree
> Affects Versions: 4.3.7
> Environment: RichFaces 4.3.7
> Mojarra 2.1.29
> Java 7 Update 67 (x64)
> Tomcat 7.0.52 (x64)
> Firefox 31
> Reporter: Michael B
>
> First of all: this is a bug report which may be related to RF-13776, since it also originates in the same spot of the JavaScript library of RichFaces.
> Preface:
> The problem is difficult to reproduce systematically, since it only seems to occur in one of n cases of loading one and the same complex xhtml (with exactly the same data from the backing bean).
> The problem is described based on the rich:tree component when clicking on the expand icon of a treeNode which fires a "ToggleEvent".
> Occasionally there is a JavaScript error in the last line of
> {code}
> richfaces.ui.TreeNode.emitToggleEvent = function(nodeId) {
> var node = document.getElementById(nodeId);
> if (!node) {
> return;
> }
> richfaces.$(node).__fireToggleEvent();
> };
> {code}
> When the problem occurs, the expression {code}richfaces.$(node){code} evaluates to 'undefined'.
> Debugging into the function when the problem occurs:
> {code:title=richfaces.$|borderStyle=solid}
> richfaces.$ = function(source) {
> var element = richfaces.getDomElement( source );
> if(element)
> {
> return( element[richfaces.RICH_CONTAINER] || {} )["component"]
> }
> };
> {code}
> While the element is correctly evaluated to the treeNode/treeNodeToggle-source, the expression {code}element[richfaces.RICH_CONTAINER]{code} evaluates to 'undefined'.
> Reloading the page one or more times produces correct results, where the attribute is set.
> To be able to provide a reproducable example of the problem, please provide some information under which circumstances the property may not be set correctly for some components. Please also give us a hint, where to debug into the RF JavaScript code to find the spot where this property is set.
> Although the problem doesn't occur all the time, it happens quite often with the effect of breaking the entire application. So for future versions I would suggest a check if {code}richfaces.$(xyz){code} evalutes to a valid result, before invoking any operations on the result and maybe write a message to the a4j:log in cases where a valid result is expected but not returned.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13154) Upgrade Atmosphere to 1.0.17 (a4j:push fails with CNFE for org.apache.coyote.http11.upgrade.UpgradeInbound on latest EAP 6)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/RF-13154?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on RF-13154:
----------------------------------------------
Jan Stefl <jstefl(a)redhat.com> changed the Status of [bug 1001854|https://bugzilla.redhat.com/show_bug.cgi?id=1001854] from NEW to CLOSED
> Upgrade Atmosphere to 1.0.17 (a4j:push fails with CNFE for org.apache.coyote.http11.upgrade.UpgradeInbound on latest EAP 6)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-13154
> URL: https://issues.jboss.org/browse/RF-13154
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.3
> Environment: EAP 6.1.1.ER7
> Reporter: Ken Finnigan
> Assignee: Brian Leathem
> Fix For: 4.3.4
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When accessing a4j:push example in showcase on EAP 6.1.1.ER7 the network tab of the developer console in Chrome shows failed network attempts for richfaces push and the following exception in the server logs:
> {code}
> 15:21:29,295 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/showcase].[AutoRegisteredPushServlet]] (http-/127.0.0.1:8080-2) JBWEB000236: Servlet.service() for servlet AutoRegisteredPushServlet threw exception: java.lang.ClassNotFoundException: org.apache.coyote.http11.upgrade.UpgradeInbound from [Module "deployment.richfaces-showcase-4.3.3.Final-jbas71.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.atmosphere.container.Tomcat7AsyncSupportWithWebSocket.service(Tomcat7AsyncSupportWithWebSocket.java:59) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1370) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:293) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:279) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) [rewrite-servlet-1.0.4.Final.jar:1.0.4.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
> Running the exact same showcase example war on EAP 6.1.0.GA works fine.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Michal Petrov edited comment on RF-13785 at 8/20/14 4:11 AM:
-------------------------------------------------------------
[~clerum], I see. That's because of the workaround for MyFaces (RF-13740). Looks like we need a more sophisticated check.
EDIT: Is this on a specific component? I see how it can fail but I've tried both metamer and showcase on Tomcat 7.0.52 and I don't see the NPE.
was (Author: michpetrov):
[~clerum], I see. That's because of the workaround for MyFaces (RF-13740). Looks like we need a more sophisticated check.
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13778) RF-45 cyclic dependency on richfaces-parent
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13778?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-13778:
------------------------------------
[~michpetrov], when are we going to update jsf-test in richfaces/build/pom.xml?
> RF-45 cyclic dependency on richfaces-parent
> -------------------------------------------
>
> Key: RF-13778
> URL: https://issues.jboss.org/browse/RF-13778
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
> Assignee: Pavel Slegr
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Historically there is a dependency in .../jsf-tests/pom.xml on richfaces-parent which used to be a standalone project/repo in 4.3.x
> {code}
> <parent>
> <groupId>org.richfaces</groupId>
> <artifactId>richfaces-parent</artifactId>
> <version>12</version>
> </parent>
> {code}
> However nowadays in 4.5.x there is playing the role of parent the
> richfaces/pom.xml
> https://github.com/richfaces/richfaces/blob/master/pom.xml
> {code}
> <groupId>org.richfaces</groupId>
> <artifactId>richfaces-parent</artifactId>
> <packaging>pom</packaging>
> <version>4.5.0-SNAPSHOT</version>
> <name>RichFaces Parent</name>
> {code}
> which makes a cyclic dependency
> jsf-test --> richfaces --> jsf-test
> as there are inside https://github.com/richfaces/richfaces/blob/master/build/pom.xml
> referenced dependencies for jsf-tests
> {code}
> <dependency>
> <groupId>org.jboss.test-jsf</groupId>
> <artifactId>htmlunit-client</artifactId>
> <version>${version.jsf-test}</version>
> <exclusions>
> <exclusion>
> <groupId>javax.servlet</groupId>
> <artifactId>javax.servlet-api</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> <dependency>
> <groupId>org.jboss.test-jsf</groupId>
> <artifactId>jsf-test-stage</artifactId>
> <version>${version.jsf-test}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.test-jsf</groupId>
> <artifactId>jsf-mock</artifactId>
> <version>${version.jsf-test}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.test-jsf</groupId>
> <artifactId>jsf-mockito</artifactId>
> <version>${version.jsf-test}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.test-jsf</groupId>
> <artifactId>jsf-test-scriptunit</artifactId>
> <version>${version.jsf-test}</version>
> </dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Michal Petrov reopened RF-13785:
--------------------------------
[~clerum], I see. That's because of the workaround for MyFaces (RF-13740). Looks like we need a more sophisticated check.
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13766) Move classes ElementIsFocused and FocusRetriever to build-resources
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13766?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13766:
----------------------------------
The issue is fixed only on feature branch: RF-12950.
This issue will be resolved once that branch is merged to master.
> Move classes ElementIsFocused and FocusRetriever to build-resources
> -------------------------------------------------------------------
>
> Key: RF-13766
> URL: https://issues.jboss.org/browse/RF-13766
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Martin Tomasek
> Assignee: Martin Tomasek
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> Move classes ElementIsFocused and FocusRetriever from components/rich/src/test/integration/org/richfaces/components/focus to build/build-resources/src/main/java/org/richfaces/utils.focus package.
> Several showcases tests use these class too. After perform https://issues.jboss.org/browse/RF-12950 showcase tests will be in richfaces repo and they will need use ElementIsFocused and FocusRetriever. Its good to have these two classes in build-resources and not duplicate them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Cody Lerum edited comment on RF-13785 at 8/19/14 3:44 PM:
----------------------------------------------------------
[~michpetrov]
I just started picking up an NPE on rev e926ef568c08ffe10fc63ab3c2ec077147b070d3
{code}
NullPointerException
org.richfaces.context.ExtendedPartialViewContext in detectRenderAll at line 347 (application)
org.richfaces.context.ExtendedPartialViewContext in isRenderAll at line 330 (application)
com.ocpsoft.pretty.faces2.application.PrettyNavigationHandler in handleNavigation at line 65 (application)
org.ocpsoft.rewrite.faces.RewriteNavigationHandler in handleNavigation at line 64 (application)
{code}
was (Author: clerum):
[~michpetrov]
I just started picking up an NPE on rev e926ef568c08ffe10fc63ab3c2ec077147b070d3
{code}
at org.richfaces.context.ExtendedPartialViewContext.detectRenderAll
at org.richfaces.context.ExtendedPartialViewContext.isRenderAll
at com.sun.faces.application.NavigationHandlerImpl.updateRenderTargets
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.ocpsoft.pretty.faces2.application.PrettyNavigationHandler.handleNavigation
at org.ocpsoft.rewrite.faces.RewriteNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.config.view.navigation.ViewConfigAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.scope.viewaccess.ViewAccessScopedAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandlerWrapper.handleNavigation
at com.sun.faces.application.ActionListenerImpl.processAction
at org.apache.deltaspike.jsf.impl.config.view.ViewControllerActionListener.processAction
at org.apache.deltaspike.jsf.impl.listener.action.DeltaSpikeActionListener.processAction
at javax.faces.component.UICommand.broadcast
at javax.faces.component.UIViewRoot.broadcastEvents
at javax.faces.component.UIViewRoot.processApplication
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute
at com.sun.faces.lifecycle.Phase.doPhase
at com.sun.faces.lifecycle.LifecycleImpl.execute
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute
at javax.faces.lifecycle.LifecycleWrapper.execute
at javax.faces.webapp.FacesServlet.service
at io.undertow.servlet.handlers.ServletHandler.handleRequest
{code}
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Cody Lerum commented on RF-13785:
---------------------------------
[~michpetrov]
I just started picking up an NPE on rev e926ef568c08ffe10fc63ab3c2ec077147b070d3
at org.richfaces.context.ExtendedPartialViewContext.detectRenderAll
at org.richfaces.context.ExtendedPartialViewContext.isRenderAll
at com.sun.faces.application.NavigationHandlerImpl.updateRenderTargets
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.ocpsoft.pretty.faces2.application.PrettyNavigationHandler.handleNavigation
at org.ocpsoft.rewrite.faces.RewriteNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.config.view.navigation.ViewConfigAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.scope.viewaccess.ViewAccessScopedAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandlerWrapper.handleNavigation
at com.sun.faces.application.ActionListenerImpl.processAction
at org.apache.deltaspike.jsf.impl.config.view.ViewControllerActionListener.processAction
at org.apache.deltaspike.jsf.impl.listener.action.DeltaSpikeActionListener.processAction
at javax.faces.component.UICommand.broadcast
at javax.faces.component.UIViewRoot.broadcastEvents
at javax.faces.component.UIViewRoot.processApplication
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute
at com.sun.faces.lifecycle.Phase.doPhase
at com.sun.faces.lifecycle.LifecycleImpl.execute
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute
at javax.faces.lifecycle.LifecycleWrapper.execute
at javax.faces.webapp.FacesServlet.service
at io.undertow.servlet.handlers.ServletHandler.handleRequest
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Cody Lerum edited comment on RF-13785 at 8/19/14 3:43 PM:
----------------------------------------------------------
[~michpetrov]
I just started picking up an NPE on rev e926ef568c08ffe10fc63ab3c2ec077147b070d3
{code}
at org.richfaces.context.ExtendedPartialViewContext.detectRenderAll
at org.richfaces.context.ExtendedPartialViewContext.isRenderAll
at com.sun.faces.application.NavigationHandlerImpl.updateRenderTargets
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.ocpsoft.pretty.faces2.application.PrettyNavigationHandler.handleNavigation
at org.ocpsoft.rewrite.faces.RewriteNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.config.view.navigation.ViewConfigAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.scope.viewaccess.ViewAccessScopedAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandlerWrapper.handleNavigation
at com.sun.faces.application.ActionListenerImpl.processAction
at org.apache.deltaspike.jsf.impl.config.view.ViewControllerActionListener.processAction
at org.apache.deltaspike.jsf.impl.listener.action.DeltaSpikeActionListener.processAction
at javax.faces.component.UICommand.broadcast
at javax.faces.component.UIViewRoot.broadcastEvents
at javax.faces.component.UIViewRoot.processApplication
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute
at com.sun.faces.lifecycle.Phase.doPhase
at com.sun.faces.lifecycle.LifecycleImpl.execute
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute
at javax.faces.lifecycle.LifecycleWrapper.execute
at javax.faces.webapp.FacesServlet.service
at io.undertow.servlet.handlers.ServletHandler.handleRequest
{code}
was (Author: clerum):
[~michpetrov]
I just started picking up an NPE on rev e926ef568c08ffe10fc63ab3c2ec077147b070d3
at org.richfaces.context.ExtendedPartialViewContext.detectRenderAll
at org.richfaces.context.ExtendedPartialViewContext.isRenderAll
at com.sun.faces.application.NavigationHandlerImpl.updateRenderTargets
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation
at com.ocpsoft.pretty.faces2.application.PrettyNavigationHandler.handleNavigation
at org.ocpsoft.rewrite.faces.RewriteNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.config.view.navigation.ViewConfigAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.scope.viewaccess.ViewAccessScopedAwareNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandler.handleNavigation
at org.apache.deltaspike.jsf.impl.navigation.DeltaSpikeNavigationHandlerWrapper.handleNavigation
at com.sun.faces.application.ActionListenerImpl.processAction
at org.apache.deltaspike.jsf.impl.config.view.ViewControllerActionListener.processAction
at org.apache.deltaspike.jsf.impl.listener.action.DeltaSpikeActionListener.processAction
at javax.faces.component.UICommand.broadcast
at javax.faces.component.UIViewRoot.broadcastEvents
at javax.faces.component.UIViewRoot.processApplication
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute
at com.sun.faces.lifecycle.Phase.doPhase
at com.sun.faces.lifecycle.LifecycleImpl.execute
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute
at javax.faces.lifecycle.LifecycleWrapper.execute
at javax.faces.webapp.FacesServlet.service
at io.undertow.servlet.handlers.ServletHandler.handleRequest
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months