December 2012 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-12650) rich:placeholder: when @rendered=false the placeholder is still rendered

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12650?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-12650: ---------------------------- Sprint: 4.3.0.M3 - EDT and AJAX > rich:placeholder: when @rendered=false the placeholder is still rendered > ------------------------------------------------------------------------ > > Key: RF-12650 > URL: https://issues.jboss.org/browse/RF-12650 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-misc > Reporter: Jiří Štefek > Priority: Minor > Labels: regression > Fix For: 4.3.0.M3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > See the steps to reproduce. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12650) rich:placeholder: when @rendered=false the placeholder is still rendered

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12650?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned RF-12650: ------------------------------- Assignee: Lukáš Fryč > rich:placeholder: when @rendered=false the placeholder is still rendered > ------------------------------------------------------------------------ > > Key: RF-12650 > URL: https://issues.jboss.org/browse/RF-12650 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-misc > Reporter: Jiří Štefek > Assignee: Lukáš Fryč > Priority: Minor > Labels: regression > Fix For: 4.3.0.M3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > See the steps to reproduce. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12650) rich:placeholder: when @rendered=false the placeholder is still rendered

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12650?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-12650: ---------------------------- Original Estimate: 15 minutes Remaining Estimate: 15 minutes > rich:placeholder: when @rendered=false the placeholder is still rendered > ------------------------------------------------------------------------ > > Key: RF-12650 > URL: https://issues.jboss.org/browse/RF-12650 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-misc > Reporter: Jiří Štefek > Priority: Minor > Labels: regression > Fix For: 4.3.0.M3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > See the steps to reproduce. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12650) rich:placeholder: when @rendered=false the placeholder is still rendered

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12650?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-12650: ---------------------------- Priority: Minor (was: Major) > rich:placeholder: when @rendered=false the placeholder is still rendered > ------------------------------------------------------------------------ > > Key: RF-12650 > URL: https://issues.jboss.org/browse/RF-12650 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-misc > Reporter: Jiří Štefek > Priority: Minor > Labels: regression > Fix For: 4.3.0.M3 > > > See the steps to reproduce. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12650) rich:placeholder: when @rendered=false the placeholder is still rendered

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12650?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-12650: ---------------------------- Fix Version/s: 4.3.0.M3 > rich:placeholder: when @rendered=false the placeholder is still rendered > ------------------------------------------------------------------------ > > Key: RF-12650 > URL: https://issues.jboss.org/browse/RF-12650 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-misc > Reporter: Jiří Štefek > Labels: regression > Fix For: 4.3.0.M3 > > > See the steps to reproduce. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12608) pickList without collectionType results in failure to lazily load

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-12608?page=com.atlassian.jira.plugin.s... ] Juraj Húska edited comment on RF-12608 at 12/11/12 7:49 AM: ------------------------------------------------------------ I switched persistence context to extended and the {{LazyInitializationException}} disappeared. Therefore I can not reproduce the issue. In this [line|https://github.com/jhuska/RF-12608/blob/master/src/main/java/org/ric...] I am printing the class of the returned collection. The output from that line is {{class org.hibernate.collection.internal.PersistentBag}}, which is some kind of runtime proxy according to [this|http://java.dzone.com/articles/jpa-lazy-loading] article, which retrieves all entities once firstly accessed. The same apply when I am not finding the runtime class of the list. Ken H., could you please confirm that the behavior align with your description ? Thanks. was (Author: jhuska): I switched persistence context to extended and the {{LazyInitializationException}} disappeared. Therefore I can not reproduce the issue. In this [line|https://github.com/jhuska/RF-12608/blob/master/src/main/java/org/ric...] I am printing the class of the returned collection. The output from that line is {{class org.hibernate.collection.internal.PersistentBag}}, which is some kind of runtime proxy according to [this|http://java.dzone.com/articles/jpa-lazy-loading] article, which retrieves all entities once firstly accessed. Ken H., could you please confirm that the behavior align with your description ? Thanks. > pickList without collectionType results in failure to lazily load > ----------------------------------------------------------------- > > Key: RF-12608 > URL: https://issues.jboss.org/browse/RF-12608 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.3.Final, 4.3.0.M2 > Reporter: Ken H > Assignee: Juraj Húska > Labels: regression, waiting_on_user > > Changes to the selectManyHelper class in 4.2.3+ causes a lazy loading exception in hibernate when the backing collection is persistent and is not eagerly loaded. > The problem seems to be that fetching the collection in SelectManyHelper.getConvertedValue bypasses the PersistentSet getter that would normally issue the lazy load request. > Defining the collectionType (e.g. java.util.ArrayList) bypasses this issue. > Ideally this method would detect Hibernate proxy collections and handle them appropriately. However, I realize that may cause a dependency so perhaps it would be enough to document this option and situation in the component reference. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12608) pickList without collectionType results in failure to lazily load

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-12608?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-12608: ----------------------------- Labels: regression waiting_on_user (was: regression) > pickList without collectionType results in failure to lazily load > ----------------------------------------------------------------- > > Key: RF-12608 > URL: https://issues.jboss.org/browse/RF-12608 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.3.Final, 4.3.0.M2 > Reporter: Ken H > Assignee: Juraj Húska > Labels: regression, waiting_on_user > > Changes to the selectManyHelper class in 4.2.3+ causes a lazy loading exception in hibernate when the backing collection is persistent and is not eagerly loaded. > The problem seems to be that fetching the collection in SelectManyHelper.getConvertedValue bypasses the PersistentSet getter that would normally issue the lazy load request. > Defining the collectionType (e.g. java.util.ArrayList) bypasses this issue. > Ideally this method would detect Hibernate proxy collections and handle them appropriately. However, I realize that may cause a dependency so perhaps it would be enough to document this option and situation in the component reference. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12608) pickList without collectionType results in failure to lazily load

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-12608?page=com.atlassian.jira.plugin.s... ] Juraj Húska commented on RF-12608: ---------------------------------- I switched persistence context to extended and the {{LazyInitializationException}} disappeared. Therefore I can not reproduce the issue. In this [line|https://github.com/jhuska/RF-12608/blob/master/src/main/java/org/ric...] I am printing the class of the returned collection. The output from that line is {{class org.hibernate.collection.internal.PersistentBag}}, which is some kind of runtime proxy according to [this|http://java.dzone.com/articles/jpa-lazy-loading] article, which retrieves all entities once firstly accessed. Ken H., could you please confirm that the behavior align with your description ? Thanks. > pickList without collectionType results in failure to lazily load > ----------------------------------------------------------------- > > Key: RF-12608 > URL: https://issues.jboss.org/browse/RF-12608 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.2.3.Final, 4.3.0.M2 > Reporter: Ken H > Assignee: Juraj Húska > Labels: regression > > Changes to the selectManyHelper class in 4.2.3+ causes a lazy loading exception in hibernate when the backing collection is persistent and is not eagerly loaded. > The problem seems to be that fetching the collection in SelectManyHelper.getConvertedValue bypasses the PersistentSet getter that would normally issue the lazy load request. > Defining the collectionType (e.g. java.util.ArrayList) bypasses this issue. > Ideally this method would detect Hibernate proxy collections and handle them appropriately. However, I realize that may cause a dependency so perhaps it would be enough to document this option and situation in the component reference. -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12144) Notify: taglib and faces-config.xml are not synced

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/RF-12144?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak closed RF-12144. ------------------------------ > Notify: taglib and faces-config.xml are not synced > -------------------------------------------------- > > Key: RF-12144 > URL: https://issues.jboss.org/browse/RF-12144 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: cdk, component > Affects Versions: 4.2.0.Final, 4.2.1.CR1, 4.3.0.M2 > Reporter: Pavol Pitonak > Assignee: Lukáš Fryč > Labels: needs-qe, vdl > Fix For: 4.3.0.M3 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > RichFaces taglig [1] and faces-config.xml [2] should contain the same information about the components. However, notify, notifyMessage, notifyMessages and notifyStack are not synced in those two files. E.g. > * faces-config.xml is missing notifyMessages' attribute animationSpeed > * attribute styleClass in notifyMessages is missing description in faces-config.xml > https://repository.jboss.org/nexus/service/local/repositories/public/arch... > https://repository.jboss.org/nexus/service/local/repositories/public/arch... -- 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

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RF-12303) Custom topiclistener not working on richfaces push component of verion 4.2.2-Final and older

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-12303?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč resolved RF-12303. ----------------------------- Resolution: Done > Custom topiclistener not working on richfaces push component of verion 4.2.2-Final and older > -------------------------------------------------------------------------------------------- > > Key: RF-12303 > URL: https://issues.jboss.org/browse/RF-12303 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core, component-push/poll > Affects Versions: 4.2.2.Final > Environment: No deponds on what environment. > Reporter: Daniel Yang > Assignee: Lukáš Fryč > Labels: push, richfaces > Fix For: 4.3.0.M3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > See description here: > https://community.jboss.org/message/736651#736651 > Copy it again: > I use it like following lines: > > {code:java} > TopicsContext topicsContext = TopicsContext.lookup(); > Topic topic = topicsContext.getOrCreateTopic(new TopicKey("test")); > topic.setMessageDataSerializer(DefaultMessageDataSerializer.instance()); > topic.addTopicListener(new SessionTopicListener2() { > @Override > public void processPreSubscriptionEvent(SessionPreSubscriptionEvent event) throws SubscriptionFailureException { > //TODO > } > @Override > public void processSubscriptionEvent(SessionSubscriptionEvent event) { > //TODO > } > @Override > public void processUnsubscriptionEvent(SessionUnsubscriptionEvent event) { > //TODO > } > }); > {code} > > I noted that listeners in TopicImpl are all the SessionTopicListener2 type, because add method is: > {code:java} > public void addTopicListener(TopicListener topicListener) { > TopicListener listener = topicListener; > if (listener instanceof SessionTopicListener) { > listener = new SessionTopicListenerWrapper((SessionTopicListener) listener); > } > listeners.add(listener); > } > {code} > > > All SessionTopicListeners are wrapped to type SessionTopicListener2, and when event publish in TopicImpl, it check it if it is appropriate listener like this: > > {code:java} > public void publishEvent(TopicEvent event) { > for (TopicListener listener : listeners) { > if (event.isAppropriateListener(listener)) { > try { > event.invokeListener(listener); > } catch (Exception e) { > logError(e); > } > } > } > } > {code} > > But event type SessionPreSubscriptionEvent, SessionSubscriptionEvent or SessionUnsubscriptionEvent does not override the mothed isAppropriateListener, so when checking, it use the method of its parent SessionTopicEvent, its parent method is like this: > {code:java} > > @Override > public boolean isAppropriateListener(EventListener listener) { > return (listener instanceof SessionTopicListener); > } > {code} > > Then it always returns false for above three SessionTopicEvent , and the custom listeners will never be called. I think it may be changed from " return (listener instanceof SessionTopicListener);" to return (listener instanceof SessionTopicListener2); or override it in seperator implementation of type SessionTopicEvent. -- 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

11 years, 11 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 December 2012