January 2014 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13317) ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13317?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reopened RF-13317: ----------------------------- > ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate() > ----------------------------------------------------------------------------------------------- > > Key: RF-13317 > URL: https://issues.jboss.org/browse/RF-13317 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.4 > Environment: Wildfly-8.0.0.Beta1, jsf-impl-2.2.3-jbossorg-1 > Reporter: Matti Bickel > Assignee: Lukáš Fryč > Priority: Critical > Labels: jsf22 > Fix For: 5.0.0.Alpha3 > > > I'm using several {{<rich:autocomplete>}} fields in a {{<h:form>}}, but have noticed the issue with several other AJAX requests: > When the response comes back, the data is fine but I get a JSF error saying > bq. During update: javax.faces.ViewState not found > Following that, no componentData is available to the Autocomplete component and no suggestions get displayed. > For reference the [javadoc for ResponseStateManager.VIEW_STATE_PARAM|https://javaserverfaces.java.net/no...] says: > {quote} > Implementations must use this constant field value as the name of the client parameter in which to save the state between requests. The id attribute must be a concatenation of the return from UIComponent.getContainerClientId(javax.faces.context.FacesContext), the return from UINamingContainer.getSeparatorChar(javax.faces.context.FacesContext), this constant field value, the separator char, and a number that is guaranteed to be unique with respect to all the other instances of this kind of client parameter in the view. > {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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13482) Photoalbum: after edit user profile view is opened the application does not respond correctly

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13482?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13482 at 1/21/14 12:59 AM: ----------------------------------------------------------- EAP 6.1.1 debugging: I have found that the popup is not rendered because the commandLink is not executed. During debugging we have revealed that doDecode method of the commandLinked's renderer is not executed. It is caused by a fact that when the component should be executed during APPLY_REQUEST_VALUES phase, the tree is traversed by EPVC and it uses JSF's native traversal mechanism to visit all components that are in EPVCI's {{executedIds}} collection (which is {{["j_idt330"]}}). But the debugging revealed that where the component {{"j_idt330"}} should be, the same component lies but with different ID ({{"j_idt666"}}). Which is somehow related to partial state saving (I would actually try to this on MyFaces). Initially I have though that it is caused by UIOutputPanelWorkaround component that wraps the commandLink, but that's not the case (when disabled it didn't help). What helped to overcome this issue is turning {{javax.faces.PARTIAL_STATE_SAVING=false}}. This can be used as workaround. However the root cause is not known yet and as [~michpetrov] pointed out, turning partial state saving off causes drag-n-drop to stop to work. was (Author: lfryc): I have found that the popup is not rendered because the commandLink is not executed. During debugging we have revealed that doDecode method of the commandLinked's renderer is not executed. It is caused by a fact that when the component should be executed during APPLY_REQUEST_VALUES phase, the tree is traversed by EPVC and it uses JSF's native traversal mechanism to visit all components that are in EPVCI's {{executedIds}} collection (which is {{["j_idt330"]}}). But the debugging revealed that where the component {{"j_idt330"}} should be, the same component lies but with different ID ({{"j_idt666"}}). Which is somehow related to partial state saving (I would actually try to this on MyFaces). Initially I have though that it is caused by UIOutputPanelWorkaround component that wraps the commandLink, but that's not the case (when disabled it didn't help). What helped to overcome this issue is turning {{javax.faces.PARTIAL_STATE_SAVING=false}}. This can be used as workaround. However the root cause is not known yet and as [~michpetrov] pointed out, turning partial state saving off causes drag-n-drop to stop to work. > Photoalbum: after edit user profile view is opened the application does not respond correctly > --------------------------------------------------------------------------------------------- > > Key: RF-13482 > URL: https://issues.jboss.org/browse/RF-13482 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.4 > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.6 > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13484) Photoalbum: cannot interact with some components in images search result view

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13484?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13484: --------------------------------- Yes, it works on EAP 6.1 now. > Photoalbum: cannot interact with some components in images search result view > ----------------------------------------------------------------------------- > > Key: RF-13484 > URL: https://issues.jboss.org/browse/RF-13484 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.5 > Environment: JBoss AS 7.1.1 > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.5 > > > Works on EAP 6.1. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13499) Scale aggressiveness of the workaround for WildFly/Push interoperability back

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13499?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13499: --------------------------------- I have checked and it is not part of [Final-SNAPSHOT build yet|https://github.com/wildfly/wildfly/blob/master/pom.xml#L108]. > Scale aggressiveness of the workaround for WildFly/Push interoperability back > ----------------------------------------------------------------------------- > > Key: RF-13499 > URL: https://issues.jboss.org/browse/RF-13499 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component-push/poll > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha4 > > > In RF-13179 we have implemented a workaround by leveraging @WebFilter annotation. This may be potentially an interoperability issue on non-JBoss containers. > I suggest to target WildFly support at the moment and scale the aggresiveness of the fix later once WildFly fixes the issue. > Once ready, it's enough to remove annotations added in RF-13179 -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13489) Photoalbum: use bigger fonts and choose some modern font-family

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13489?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13489: ------------------------------- Description: The photoalbum has relatively small fonts, the overall look of the demo would benefit from increasing the font-size and eventually changing the font-family. Fonts: http://www.google.com/fonts was: The photoalbum has relatively small fonts, the overall look of the demo would benefit from increasing a font-size and eventually changing a font-family. Fonts: http://www.google.com/fonts > Photoalbum: use bigger fonts and choose some modern font-family > --------------------------------------------------------------- > > Key: RF-13489 > URL: https://issues.jboss.org/browse/RF-13489 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.5 > Reporter: Lukáš Fryč > Labels: photoalbum > > The photoalbum has relatively small fonts, the overall look of the demo would benefit from increasing the font-size and eventually changing the font-family. > Fonts: http://www.google.com/fonts -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13482) Photoalbum: after edit user profile view is opened the application does not respond correctly

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13482?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13482: ------------------------------- Fix Version/s: 4.3.6 (was: 4.3.5) > Photoalbum: after edit user profile view is opened the application does not respond correctly > --------------------------------------------------------------------------------------------- > > Key: RF-13482 > URL: https://issues.jboss.org/browse/RF-13482 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.4 > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.6 > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13484) Photoalbum: cannot interact with some components in images search result view

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13484?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13484: ------------------------------------ Is this also container specific as is RF-13482? > Photoalbum: cannot interact with some components in images search result view > ----------------------------------------------------------------------------- > > Key: RF-13484 > URL: https://issues.jboss.org/browse/RF-13484 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.5 > Environment: JBoss AS 7.1.1 > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.5 > > > Works on EAP 6.1. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13482) Photoalbum: after edit user profile view is opened the application does not respond correctly

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13482?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13482: ------------------------------------ It may be related to the use of dynamic {{ui:includes}} in the application. This is an interesting problem and warrants further investigation. This may explain why it works in EAP 6.1 but not AS 7 since EAP has a newer JSF and this issue may have been resolved upstream. Since it is container specific and works in EAP 6.1 I do not consider it a blocker for the 4.3.5 release. > Photoalbum: after edit user profile view is opened the application does not respond correctly > --------------------------------------------------------------------------------------------- > > Key: RF-13482 > URL: https://issues.jboss.org/browse/RF-13482 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Affects Versions: 4.3.4 > Reporter: Jiří Štefek > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.5 > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-13480) Java package re-structure for the photoalbum demo

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13480?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13480: ------------------------------------ Feel free to mark this issue as resolved [~michpetrov] > Java package re-structure for the photoalbum demo > ------------------------------------------------- > > Key: RF-13480 > URL: https://issues.jboss.org/browse/RF-13480 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: examples > Reporter: Brian Leathem > Assignee: Michal Petrov > Labels: photoalbum > Fix For: 4.3.5 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > This issue addresses the cleanup of the java package namespace of the demo. > 1) The package _org.richfaces.photoalbum.bean_ contains the single class _UserBean_. Let's rename the package to something less generic like _user_ or consider merging it into another pre-existing package like _ui_. > 2) The _event_ package is separate from the _domain_ package. Let's consider moving the _event_ package to be a sub-package of _domain_. While we are at it, I find the package name _model_ to be more descriptive than _domain_. > 3) The _services_ package may be better described as an _actions_ package. > 4) The _util_ package is too generic. Consider creating _converters_ and _validators_ packages to hold the bulk of these classes. Additionally the classnames _*Stuff_ and _Utils_ could be named less generically. > 5) having the two top-level classes _search_ and _ejbsearch_ is confusing. Can one package be a sub-folder of the other? Alternatively could one be in the _ui_ folder, or the other in a _model_ folder? -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (RF-7248) a4j creates infinite HashMap.get loop

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-7248?page=com.atlassian.jira.plugin.sy... ] Brian Leathem edited comment on RF-7248 at 1/20/14 10:07 PM: ------------------------------------------------------------- Thank you Brian, I will check that regards Dennis was (Author: xannis): Thank you Brian, I will check that regards Dennis Date: Fri, 17 Jan 2014 19:28:33 -0500 From: issues(a)jboss.org To: diwhermsdorf(a)hotmail.com Subject: [JBoss JIRA] (RF-7248) a4j creates infinite HashMap.get loop Brian Leathem commented on RF-7248 a4j creates infinite HashMap.get loop Dennis Hermsdorf unfortunately RichFaces 3 is not undergoing any more active development. If you need legacy support for production systems please check out the WFK product from Red Hat: http://www.redhat.com/products/jbossenterprisemiddleware/web-framework-kit/ But even there RichFaces 3 is approaching EOL. 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 > a4j creates infinite HashMap.get loop > ------------------------------------- > > Key: RF-7248 > URL: https://issues.jboss.org/browse/RF-7248 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 3.3.0, 3.3.3.Final > Reporter: Nida Cibulskyte > Assignee: Nick Belaevski > Labels: ENT > Fix For: 3.3.1.SP2, 3.3.4.BETA1 > > Attachments: infinite_loop.JPG, screenshot-1.jpg > > > Concurrent requests on a4j components causes infinite loop. While one request is being proccessed by restoreChildState method, another request is senT for proccessing. It causes the code to get stuck in hashmap.get() as the hashmap is not synchronized and causes infinite loop. > 2009 05 25 09:41:43 ERROR demo.NameBean - java.util.HashMap.get(HashMap.java:303) > 2009 05 25 09:41:43 ERROR demo.NameBean - org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965) > 2009 05 25 09:41:43 ERROR demo.NameBean - org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:982) > 2009 05 25 09:41:43 ERROR demo.NameBean - org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:982) > ....................... -- 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, 8 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 January 2014