[JBoss JIRA] (RF-11427) rich:tab - actionListener
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-11427?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-11427:
------------------------------------
It's my fault. The correct steps to reproduce are:
# git clone https://github.com/richfaces/richfaces-qa.git
# cd richfaces-qa
# git checkout 4.3.x
# mvn clean install -DskipTests
# cd metamer/ftest
# mvn clean verify -P jbossas-managed-7-1 -Dtest=TestTabPanel#testImmediate
> rich:tab - actionListener
> -------------------------
>
> Key: RF-11427
> URL: https://issues.jboss.org/browse/RF-11427
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.0.0.Final, 4.1.0.Milestone2, 4.2.3.CR1
> Environment: RichFaces 4.1.0-SNAPSHOT r.5debbf8981de1839984bdaa38b31f58ed028239d
> Metamer 4.1.0-SNAPSHOT r.22728
> Mojarra 2.1.2-FCS
> Apache Tomcat 7.0.16
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
> RichFaces 4.2.1-SNAPSHOT
> Metamer 4.2.1-SNAPSHOT
> Mojarra 2.1.7-jbossorg-1
> JBoss AS 7.1.1.Final
> Java(TM) SE Runtime Environment 1.6.0_26-b03 @ Linux
> Chrome 18.0.1025.168 @ Linux i686
> Reporter: Jan Papousek
> Labels: ci_issue
> Fix For: 5-Tracking
>
>
> It seems that the actionListener attribute doesn't work.
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # open tab2
> # open tab1 (action and action listener are invoked)
> # open tab2
> # open tab1 (action and action listener are *NOT* invoked)
> # open tab1 (action and action listener are invoked)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13592) a4j:push doesn't work after rendering
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13592?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13592:
-------------------------------
Labels: waiting_on_user (was: )
> a4j:push doesn't work after rendering
> -------------------------------------
>
> Key: RF-13592
> URL: https://issues.jboss.org/browse/RF-13592
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.3.5
> Environment: JBoss EAP 6.2
> Browser: Chrome 33.0.1750.154 and IE 8.0.7601.17514
> JSF 2.19, Richfaces 4.3.5
> Reporter: Igor Bolshakov
> Assignee: Pavol Pitonak
> Priority: Critical
> Labels: waiting_on_user
> Attachments: a4j.log, localhost.har, screenshot.png, web.xml
>
>
> I use {{rendered}} attribute to start/stop a4j:push component in example below. After rendering of a4j:push element the handling of incoming push messages is broken. In my simple example I set alert to notify about recieved message (see attached screenshot).
> View xhtml code:
> {code:xml}<?xml version="1.0" encoding="ISO-8859-1"?>
> <ui:composition xmlns="http://www.w3.org/1999/xhtml"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:form>
> <a4j:outputPanel id="push-panel">
> <a4j:push address="TEST_ADDRESS" ondataavailable="alert('event.rf.data=' + event.rf.data)"
> rendered="#{testBean.enabled}"/>
> </a4j:outputPanel>
> <a4j:commandButton id="startBtn" value="Start Push" action="#{testBean.startPush}" render="push-panel"/>
> <a4j:commandButton id="stopBtn" value="Stop Push" action="#{testBean.stopPush}" render="push-panel"/>
> <a4j:commandButton id="sendMessage" value="Send Message" action="#{testBean.sendMessage}"/>
> </h:form>
> </ui:composition>{code}
> Backing bean class:
> {code}public class TestBean {
> private boolean enabled = false;
> public boolean isEnabled() {
> return enabled;
> }
> public void startPush() {
> enabled = true;
> }
> public void stopPush() {
> enabled = false;
> }
> public void sendMessage() throws MessageException {
> TopicsContext.lookup().publish(new TopicKey("TEST_ADDRESS"), "Hello World");
> }
> }{code}
> Configuration in web.xml (see attachment).
> Scenario:
> 1) Open page
> 2) Click "Start Push" button
> 3) Click "Send Message" button
> 4) Alert "event.rf.data=Hello World" is shown (see attached screenshot)
> 5) Click "Stop Push" button
> 6) Polling is closed (see localhost.har in attachment)
> 7) Click "Start Push" button
> 8) Polling is started (see localhost.har in attachment)
> 9) Click "Send Message" button
> 10) Message is recieved (see localhost.har in attachment)
> 11) No alert, no javascript error
> For more details I saved a4j:log output in a4j.log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13592) a4j:push doesn't work after rendering
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13592?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-13592:
------------------------------------
I could not reproduce in Metamer.
[~igor_ab], according to web.xml and localhost.har it seems that you're running a portlet. Can you reproduce outside of portal environment? Secondly, it's normal that a4j:push starts working after some time (in my environment ca. 20 seconds). Can you try to enable the push, disable it, enable it again and wait 20-30 second before generating a message?
> a4j:push doesn't work after rendering
> -------------------------------------
>
> Key: RF-13592
> URL: https://issues.jboss.org/browse/RF-13592
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.3.5
> Environment: JBoss EAP 6.2
> Browser: Chrome 33.0.1750.154 and IE 8.0.7601.17514
> JSF 2.19, Richfaces 4.3.5
> Reporter: Igor Bolshakov
> Assignee: Pavol Pitonak
> Priority: Critical
> Attachments: a4j.log, localhost.har, screenshot.png, web.xml
>
>
> I use {{rendered}} attribute to start/stop a4j:push component in example below. After rendering of a4j:push element the handling of incoming push messages is broken. In my simple example I set alert to notify about recieved message (see attached screenshot).
> View xhtml code:
> {code:xml}<?xml version="1.0" encoding="ISO-8859-1"?>
> <ui:composition xmlns="http://www.w3.org/1999/xhtml"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:form>
> <a4j:outputPanel id="push-panel">
> <a4j:push address="TEST_ADDRESS" ondataavailable="alert('event.rf.data=' + event.rf.data)"
> rendered="#{testBean.enabled}"/>
> </a4j:outputPanel>
> <a4j:commandButton id="startBtn" value="Start Push" action="#{testBean.startPush}" render="push-panel"/>
> <a4j:commandButton id="stopBtn" value="Stop Push" action="#{testBean.stopPush}" render="push-panel"/>
> <a4j:commandButton id="sendMessage" value="Send Message" action="#{testBean.sendMessage}"/>
> </h:form>
> </ui:composition>{code}
> Backing bean class:
> {code}public class TestBean {
> private boolean enabled = false;
> public boolean isEnabled() {
> return enabled;
> }
> public void startPush() {
> enabled = true;
> }
> public void stopPush() {
> enabled = false;
> }
> public void sendMessage() throws MessageException {
> TopicsContext.lookup().publish(new TopicKey("TEST_ADDRESS"), "Hello World");
> }
> }{code}
> Configuration in web.xml (see attachment).
> Scenario:
> 1) Open page
> 2) Click "Start Push" button
> 3) Click "Send Message" button
> 4) Alert "event.rf.data=Hello World" is shown (see attached screenshot)
> 5) Click "Stop Push" button
> 6) Polling is closed (see localhost.har in attachment)
> 7) Click "Start Push" button
> 8) Polling is started (see localhost.har in attachment)
> 9) Click "Send Message" button
> 10) Message is recieved (see localhost.har in attachment)
> 11) No alert, no javascript error
> For more details I saved a4j:log output in a4j.log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13452) UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-13452?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich edited comment on RF-13452 at 4/2/14 7:42 AM:
----------------------------------------------------------
Some notes on the issue:
First, it seems redundant that {{UIDataAdaptor}} subscribes itself for {{PostRestoreStateEvent}}.
If I get the JSF specification right (JSF 2.0, section 2.2.1), processEvent(ComponentSystemEvent) has to be invoked by the JSF implementation anyway for each UIComponent when it is restored. Debugging Mojarra (2.1.28) indicates that this actually happens.
Furthermore, I just added a workaround description. The most simple solution for you to fix the problem seems to be to just implement some {{ComponentSystemEventListener}} and register an instance of that class on the {{UIDataAdaptor}} for {{PostAddToViewEvent}}, instead of the {{UIDataAdaptor}}. The listener's implementation of {{processEvent(ComponentSystemEvent)}} just delegates: {{event.getComponent().processEvent(event)}}.
Also note that {{UIFileUpload}} imposes a similar Problem, because {{AbstractFileUpload}} is a listener for {{PostAddToViewEvent}} by annotation as well.
was (Author: lutzulrich):
Some notes on the issue:
First, it seems redundant that UIDataAdaptor subscribes itself for {{PostRestoreStateEvent}}.
If I get the JSF specification right (JSF 2.0, section 2.2.1), processEvent(ComponentSystemEvent) has to be invoked by the JSF implementation anyway for each UIComponent when it is restored. Debugging Mojarra (2.1.28) indicates that this actually happens.
Furthermore, I just added a workaround description. The most simple solution for you to fix the Problem seems to be to just implement some {{ComponentSystemEventListener}} and register an instance of that class on the {{UIDataAdaptor}} for {{PostAddToViewEvent}}, instead of the {{UIDataAdaptor}}. The listener's implementation of {{processEvent(ComponentSystemEvent)}} just delegates: {{event.getComponent().processEvent(event)}}.
> UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
> -------------------------------------------------------------------------------------
>
> Key: RF-13452
> URL: https://issues.jboss.org/browse/RF-13452
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.4, 4.3.5
> Environment: Mojarra 2.1.?? - 2.1.28
> Reporter: Lutz Ulrich
> Labels: UIDataAdaptor, UIDataTable, dynamical-add
> Fix For: 5-Tracking
>
>
> Whenever a component which is based on {{org.richfaces.component.UIDataAdaptor}} is added dynamically, NPE occurs in the next RESTORE_VIEW Phase when using Mojarra 2.1.x.
> My first guess was, that this would be an error in Mojarra (issue 2152, see https://java.net/jira/browse/JAVASERVERFACES-2152?page=com.atlassian.jira... ),
> which occurs whenever a sub-class of {{UIComponent}} registers itself as {{javax.faces.event.SystemEventListener}} for
> {{javax.faces.event.PostAddToViewEvent}} in ist constructor, just like {{UIDataAdaptor}} does.
> Now, Manfred Riem of Mojarra argues (in the very issue named above), that registering for PostAddToView in the constructor is a design flaw in itself.
> Note that the error occurs with every UIComponent which is added dynamically and which registers itself as PostAddToView listener in its constructor. For the Mojarra issue, I provided a simple component which extends the standard JSF HtmlOutputText and registers itself in its constructor, too. Baam - same error. So maybe more components of RichFaces are affected - not just those based on {{UIDataAdaptor}}.
> For completion, here is a stack trace:
> {quote}
> Schwerwiegend: java.lang.NullPointerException
> at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247)
> at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2203)
> at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1885)
> at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:405)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2637)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2609)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicAdd(FaceletPartialStateManagementStrategy.java:421)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicActions(FaceletPartialStateManagementStrategy.java:247)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:570)
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:653)
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-11427) rich:tab - actionListener
by Valiantsin Shukaila (JIRA)
[ https://issues.jboss.org/browse/RF-11427?page=com.atlassian.jira.plugin.s... ]
Valiantsin Shukaila commented on RF-11427:
------------------------------------------
Maybe I can contact you for instructions in more intercative way somewhere? The last command fails for me. I spent few hours trying to run it, on jbossas-managed-7-1 it doesn't launch at all because can not find some kind of server config or soemthing like that. When I tried launching on jbossas-managed-7 profile it launches but firefox blinks with 404 page and test fails at the beginning.
Need to have some detailed instruction on running this.
> rich:tab - actionListener
> -------------------------
>
> Key: RF-11427
> URL: https://issues.jboss.org/browse/RF-11427
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.0.0.Final, 4.1.0.Milestone2, 4.2.3.CR1
> Environment: RichFaces 4.1.0-SNAPSHOT r.5debbf8981de1839984bdaa38b31f58ed028239d
> Metamer 4.1.0-SNAPSHOT r.22728
> Mojarra 2.1.2-FCS
> Apache Tomcat 7.0.16
> OpenJDK Runtime Environment 1.6.0_22-b22 @ Linux
> Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
> RichFaces 4.2.1-SNAPSHOT
> Metamer 4.2.1-SNAPSHOT
> Mojarra 2.1.7-jbossorg-1
> JBoss AS 7.1.1.Final
> Java(TM) SE Runtime Environment 1.6.0_26-b03 @ Linux
> Chrome 18.0.1025.168 @ Linux i686
> Reporter: Jan Papousek
> Labels: ci_issue
> Fix For: 5-Tracking
>
>
> It seems that the actionListener attribute doesn't work.
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # open tab2
> # open tab1 (action and action listener are invoked)
> # open tab2
> # open tab1 (action and action listener are *NOT* invoked)
> # open tab1 (action and action listener are invoked)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13452) UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-13452?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich commented on RF-13452:
----------------------------------
Some notes on the issue:
First, it seems redundant that UIDataAdaptor subscribes itself for {{PostRestoreStateEvent}}.
If I get the JSF specification right (JSF 2.0, section 2.2.1), processEvent(ComponentSystemEvent) has to be invoked by the JSF implementation anyway for each UIComponent when it is restored. Debugging Mojarra (2.1.28) indicates that this actually happens.
Furthermore, I just added a workaround description. The most simple solution for you to fix the Problem seems to be to just implement some {{ComponentSystemEventListener}} and register an instance of that class on the {{UIDataAdaptor}} for {{PostAddToViewEvent}}, instead of the {{UIDataAdaptor}}. The listener's implementation of {{processEvent(ComponentSystemEvent)}} just delegates: {{event.getComponent().processEvent(event)}}.
> UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
> -------------------------------------------------------------------------------------
>
> Key: RF-13452
> URL: https://issues.jboss.org/browse/RF-13452
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.4
> Environment: Mojarra 2.1.?? - 2.1.26
> Reporter: Lutz Ulrich
> Labels: UIDataAdaptor, UIDataTable, dynamical-add
> Fix For: 5-Tracking
>
>
> Whenever a component which is based on {{org.richfaces.component.UIDataAdaptor}} is added dynamically, NPE occurs in the next RESTORE_VIEW Phase when using Mojarra 2.1.x.
> My first guess was, that this would be an error in Mojarra (issue 2152, see https://java.net/jira/browse/JAVASERVERFACES-2152?page=com.atlassian.jira... ),
> which occurs whenever a sub-class of {{UIComponent}} registers itself as {{javax.faces.event.SystemEventListener}} for
> {{javax.faces.event.PostAddToViewEvent}} in ist constructor, just like {{UIDataAdaptor}} does.
> Now, Manfred Riem of Mojarra argues (in the very issue named above), that registering for PostAddToView in the constructor is a design flaw in itself.
> Note that the error occurs with every UIComponent which is added dynamically and which registers itself as PostAddToView listener in its constructor. For the Mojarra issue, I provided a simple component which extends the standard JSF HtmlOutputText and registers itself in its constructor, too. Baam - same error. So maybe more components of RichFaces are affected - not just those based on {{UIDataAdaptor}}.
> For completion, here is a stack trace:
> {quote}
> Schwerwiegend: java.lang.NullPointerException
> at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247)
> at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2203)
> at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1885)
> at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:405)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2637)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2609)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicAdd(FaceletPartialStateManagementStrategy.java:421)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicActions(FaceletPartialStateManagementStrategy.java:247)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:570)
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:653)
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13452) UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-13452?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich updated RF-13452:
-----------------------------
Affects Version/s: 4.3.5
> UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
> -------------------------------------------------------------------------------------
>
> Key: RF-13452
> URL: https://issues.jboss.org/browse/RF-13452
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.4, 4.3.5
> Environment: Mojarra 2.1.?? - 2.1.28
> Reporter: Lutz Ulrich
> Labels: UIDataAdaptor, UIDataTable, dynamical-add
> Fix For: 5-Tracking
>
>
> Whenever a component which is based on {{org.richfaces.component.UIDataAdaptor}} is added dynamically, NPE occurs in the next RESTORE_VIEW Phase when using Mojarra 2.1.x.
> My first guess was, that this would be an error in Mojarra (issue 2152, see https://java.net/jira/browse/JAVASERVERFACES-2152?page=com.atlassian.jira... ),
> which occurs whenever a sub-class of {{UIComponent}} registers itself as {{javax.faces.event.SystemEventListener}} for
> {{javax.faces.event.PostAddToViewEvent}} in ist constructor, just like {{UIDataAdaptor}} does.
> Now, Manfred Riem of Mojarra argues (in the very issue named above), that registering for PostAddToView in the constructor is a design flaw in itself.
> Note that the error occurs with every UIComponent which is added dynamically and which registers itself as PostAddToView listener in its constructor. For the Mojarra issue, I provided a simple component which extends the standard JSF HtmlOutputText and registers itself in its constructor, too. Baam - same error. So maybe more components of RichFaces are affected - not just those based on {{UIDataAdaptor}}.
> For completion, here is a stack trace:
> {quote}
> Schwerwiegend: java.lang.NullPointerException
> at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247)
> at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2203)
> at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1885)
> at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:405)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2637)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2609)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicAdd(FaceletPartialStateManagementStrategy.java:421)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicActions(FaceletPartialStateManagementStrategy.java:247)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:570)
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:653)
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months