April 2014 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13505 at 4/30/14 5:40 AM: ---------------------------------------------------------- For the current status: *Compatibility* * [Mojarra 2.2.6 is released|https://java.net/jira/secure/ReleaseNote.jspa?projectId=10204&ve...] with the patch included ** included in WildFly 8.1.0.CR1 * [Mojarra 2.2.5-jbossorg-3|https://github.com/jboss/mojarra/commits/2.2.5-jbossorg-3] contains this patch for 3 months now ** included in WildFly 8.0.0.Final * MyFaces 2.x was always compatible ** in theory, but some testing might be needed (tests pass as far as I can remember) * risks ** patch is not included in GlassFish 4.0 - we will need to tell people using GF to upgrade manually Suggested action items: * re-test compatibility with 4.5 branch ** run integration tests for PartialViewContext on WildFly 8.1.0.CR1 and MyFaces 2.2.x was (Author: lfryc): For the current status: *Compatibility* * [Mojarra 2.2.6 is released|https://java.net/jira/secure/ReleaseNote.jspa?projectId=10204&ve...] with the patch included ** included in WildFly 8.1.0.CR1 * [Mojarra 2.2.5-jbossorg-3|https://github.com/jboss/mojarra/commits/2.2.5-jbossorg-3] contains this patch for 3 months now ** included in WildFly 8.0.0.Final * MyFaces 2.x was always compatible ** in theory, but some testing might be needed (tests pass as far as I can remember) * risks ** patch is not included in GlassFish 4.0 > Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue) > ----------------------------------------------------------------------------------------------------------------- > > Key: RF-13505 > URL: https://issues.jboss.org/browse/RF-13505 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151 > We will still need to use some: > * resolve values in runtime > * add IDs for execution of AjaxOutput's > * collect list of meta-components to render > * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13505: --------------------------------- For the current status: *Compatibility* * [Mojarra 2.2.6 is released|https://java.net/jira/secure/ReleaseNote.jspa?projectId=10204&ve...] with the patch included ** included in WildFly 8.1.0.CR1 * [Mojarra 2.2.5-jbossorg-3|https://github.com/jboss/mojarra/commits/2.2.5-jbossorg-3] contains this patch for 3 months now ** included in WildFly 8.0.0.Final * MyFaces 2.x was always compatible ** in theory, but some testing might be needed (tests pass as far as I can remember) * risks ** patch is not included in GlassFish 4.0 > Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue) > ----------------------------------------------------------------------------------------------------------------- > > Key: RF-13505 > URL: https://issues.jboss.org/browse/RF-13505 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151 > We will still need to use some: > * resolve values in runtime > * add IDs for execution of AjaxOutput's > * collect list of meta-components to render > * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13505: --------------------------------- [~bleathem] no, it still resides in the [branch|https://github.com/richfaces/richfaces/tree/RF-13505-refactor-epvc-3]. I'm currently determining what's the status - whether we have good conditions to merge it. > Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue) > ----------------------------------------------------------------------------------------------------------------- > > Key: RF-13505 > URL: https://issues.jboss.org/browse/RF-13505 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: 4.5.0.Alpha3 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151 > We will still need to use some: > * resolve values in runtime > * add IDs for execution of AjaxOutput's > * collect list of meta-components to render > * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13621) IE11 Changes DOM structure on JSF rerender

by Robert Becker (JIRA)

[ https://issues.jboss.org/browse/RF-13621?page=com.atlassian.jira.plugin.s... ] Robert Becker updated RF-13621: ------------------------------- Description: When rerendering regions with multiple child elements, IE11 breaks the DOM by nesting the former siblings. I tried changing sarrissa as described in this issue: https://issues.jboss.org/browse/RF-13443 But it does not seem related or helping. This stackoverflow question describes the issue perfectly: http://stackoverflow.com/questions/22015352/ie11-changes-dom-structure-on... Here is a screenshot where this problem leads to multiple pagination controls, as the old dom elements reside instead of being replaced when rerendering: https://dl.dropboxusercontent.com/u/18449425/permanent/richfaces%20ie11%2... was: When rerendering regions with multiple child elements, IE11 breaks the DOM by nesting the former siblings. I tried changing sarrissa as described in this issue: https://issues.jboss.org/browse/RF-13443 But it does not seem related or helping. This stackoverflow question describes the issue perfectly: http://stackoverflow.com/questions/22015352/ie11-changes-dom-structure-on... I'll attach a screenshot where this problem leads to multiple pagination controls, as the old dom elements reside instead of being replaced when rerendering. > IE11 Changes DOM structure on JSF rerender > ------------------------------------------ > > Key: RF-13621 > URL: https://issues.jboss.org/browse/RF-13621 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: base functionality > Affects Versions: 3.3.4.Final > Reporter: Robert Becker > > When rerendering regions with multiple child elements, IE11 breaks the DOM by nesting the former siblings. > I tried changing sarrissa as described in this issue: https://issues.jboss.org/browse/RF-13443 > But it does not seem related or helping. > This stackoverflow question describes the issue perfectly: > http://stackoverflow.com/questions/22015352/ie11-changes-dom-structure-on... > Here is a screenshot where this problem leads to multiple pagination controls, as the old dom elements reside instead of being replaced when rerendering: https://dl.dropboxusercontent.com/u/18449425/permanent/richfaces%20ie11%2... -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13621) IE11 Changes DOM structure on JSF rerender

by Robert Becker (JIRA)

Robert Becker created RF-13621: ---------------------------------- Summary: IE11 Changes DOM structure on JSF rerender Key: RF-13621 URL: https://issues.jboss.org/browse/RF-13621 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: base functionality Affects Versions: 3.3.4.Final Reporter: Robert Becker When rerendering regions with multiple child elements, IE11 breaks the DOM by nesting the former siblings. I tried changing sarrissa as described in this issue: https://issues.jboss.org/browse/RF-13443 But it does not seem related or helping. This stackoverflow question describes the issue perfectly: http://stackoverflow.com/questions/22015352/ie11-changes-dom-structure-on... I'll attach a screenshot where this problem leads to multiple pagination controls, as the old dom elements reside instead of being replaced when rerendering. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13512) Photoalbum: port fix from RF-13498 to RF4 photoalbum

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/RF-13512?page=com.atlassian.jira.plugin.s... ] Michal Petrov resolved RF-13512. -------------------------------- Resolution: Done > Photoalbum: port fix from RF-13498 to RF4 photoalbum > ---------------------------------------------------- > > Key: RF-13512 > URL: https://issues.jboss.org/browse/RF-13512 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: examples > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.7 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13592) a4j:push doesn't work after rendering

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13592?page=com.atlassian.jira.plugin.s... ] Brian Leathem resolved RF-13592. -------------------------------- Resolution: Done > 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: Brian Leathem > Priority: Critical > Labels: gss, needs-qe > Fix For: 4.3.7 > > Attachments: a4j.log, localhost.har, push-test.zip, push-test.zip, screenshot.png, web.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13592) a4j:push doesn't work after rendering

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13592?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13592: ------------------------------- Sprint: 4.3.7 Sprint 1 (was: 4.3.7 Sprint 2) > 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: Brian Leathem > Priority: Critical > Labels: gss, needs-qe > Fix For: 4.3.7 > > Attachments: a4j.log, localhost.har, push-test.zip, push-test.zip, screenshot.png, web.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13592) a4j:push doesn't work after rendering

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13592?page=com.atlassian.jira.plugin.s... ] Brian Leathem reopened RF-13592: -------------------------------- > 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: Brian Leathem > Priority: Critical > Labels: gss, needs-qe > Fix For: 4.3.7 > > Attachments: a4j.log, localhost.har, push-test.zip, push-test.zip, screenshot.png, web.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13598) Richfaces 4.3.5.Final ajax calls broke with JSF2.1.28

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13598?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13598: ------------------------------------ [~ppitonak] please share your re-producing code. Also, given that this was caused by a mojarra change, it would be useful to try and reproduce this with Vanilla JSF (as requested in the forum thread). Finally, please confirm which browsers this affects. > Richfaces 4.3.5.Final ajax calls broke with JSF2.1.28 > ------------------------------------------------------ > > Key: RF-13598 > URL: https://issues.jboss.org/browse/RF-13598 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: compatibility > Affects Versions: 4.2.3.Final, 4.3.5 > Environment: Tomcat 7.0.50, Richfaces 4.3.5.Final, JSF 2.1.28, client side: IE8+ > Reporter: Wang Liyu > Assignee: Brian Leathem > Priority: Critical > Fix For: 4.3.7 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > See the https://community.jboss.org/thread/239391 -- 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, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues April 2014