April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6823) Warning if no JDBC drivers can be found in domain mode

by Heiko Braun (JIRA)

Heiko Braun created AS7-6823: -------------------------------- Summary: Warning if no JDBC drivers can be found in domain mode Key: AS7-6823 URL: https://issues.jboss.org/browse/AS7-6823 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 8.0.0.Alpha1 -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6759) Console should react properly to loss of connection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6759?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-6759: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=910718 > Console should react properly to loss of connection > --------------------------------------------------- > > Key: AS7-6759 > URL: https://issues.jboss.org/browse/AS7-6759 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Harald Pehl > Labels: console_1.5.3, merged > > Codesplit error handling leads to freeze -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-66) It is impossible to switch off URL caching if https protocol is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-66?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-66: ----------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 913252|https://bugzilla.redhat.com/show_bug.cgi?id=913252] Verified on 5.3.1.BRMS-P02. > It is impossible to switch off URL caching if https protocol is used > -------------------------------------------------------------------- > > Key: DROOLS-66 > URL: https://issues.jboss.org/browse/DROOLS-66 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > It is impossible to switch off URL caching if https protocol is used > When used https to load resources from HTTP, a conditional mistake try to cache the content even though CACHE_DIR is null: > // class org.drools.io.impl.UrlResource > public InputStream getInputStream() throws IOException { > (...) > if (lastMod > 0 && lastMod > lastRead) { > if (CACHE_DIR != null && url.getProtocol().equals("http") || url.getProtocol().equals("https")) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } > } > (...) > } > IF only "https" was evaluated as true - ((false && false) || true) - so the exit will be true, which should be not the expected behaviour > That code should be: > if (CACHE_DIR != null && (url.getProtocol().equals("http") || url.getProtocol().equals("https"))) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-66) It is impossible to switch off URL caching if https protocol is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-66?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-66: ----------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 913252|https://bugzilla.redhat.com/show_bug.cgi?id=913252] from ON_QA to VERIFIED > It is impossible to switch off URL caching if https protocol is used > -------------------------------------------------------------------- > > Key: DROOLS-66 > URL: https://issues.jboss.org/browse/DROOLS-66 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > It is impossible to switch off URL caching if https protocol is used > When used https to load resources from HTTP, a conditional mistake try to cache the content even though CACHE_DIR is null: > // class org.drools.io.impl.UrlResource > public InputStream getInputStream() throws IOException { > (...) > if (lastMod > 0 && lastMod > lastRead) { > if (CACHE_DIR != null && url.getProtocol().equals("http") || url.getProtocol().equals("https")) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } > } > (...) > } > IF only "https" was evaluated as true - ((false && false) || true) - so the exit will be true, which should be not the expected behaviour > That code should be: > if (CACHE_DIR != null && (url.getProtocol().equals("http") || url.getProtocol().equals("https"))) { > //lets grab a copy and cache it in case we need it in future... > cacheStream(); > } -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5904) CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5904?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5904: ---------------------------------------------- Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 901178|https://bugzilla.redhat.com/show_bug.cgi?id=901178] Verified on EAP 6.1.0.ER3. Given that we (EAP clustering QA) didn't file this bug, I've just verified the presence of the patch. If Radim wants to verify this himself, I'm of course fine with that :-) > CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail > -------------------------------------------------------------------------------- > > Key: AS7-5904 > URL: https://issues.jboss.org/browse/AS7-5904 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.3.Final (EAP) > Reporter: Radim Vansa > Assignee: Paul Ferraro > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > HotRod connector startup often fails in JDG 6.1.0.ER2. This is caused by early initialization of the JGroups stack, where the node can join cluster sooner than Infinispan is properly initialized, specifically sooner than the JGroupsTransport class initializes the JGroups channel and related RPC dispatcher. > In some early phase of startup each node with HotRod connector inserts data with key nodeName/clusterName into __hotRodTopologyCache (this is a replicated one). The PutKeyValueCommand is broadcasted to all nodes in the cluster, including the node which joined the cluster but where the Infinispan has not started yet. As there is no RPC dispatcher on the destination node, the message gets discarded, but source node requesting GET_ALL reponses waits for the response for 4 minutes (default timeout) and then gets an exception failing the HotRod connector. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5904) CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5904?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5904: ---------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 901178|https://bugzilla.redhat.com/show_bug.cgi?id=901178] from ON_QA to VERIFIED > CLONE - JGroups startup before ISPN startup causes HotRod connector startup fail > -------------------------------------------------------------------------------- > > Key: AS7-5904 > URL: https://issues.jboss.org/browse/AS7-5904 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.3.Final (EAP) > Reporter: Radim Vansa > Assignee: Paul Ferraro > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > HotRod connector startup often fails in JDG 6.1.0.ER2. This is caused by early initialization of the JGroups stack, where the node can join cluster sooner than Infinispan is properly initialized, specifically sooner than the JGroupsTransport class initializes the JGroups channel and related RPC dispatcher. > In some early phase of startup each node with HotRod connector inserts data with key nodeName/clusterName into __hotRodTopologyCache (this is a replicated one). The PutKeyValueCommand is broadcasted to all nodes in the cluster, including the node which joined the cluster but where the Infinispan has not started yet. As there is no RPC dispatcher on the destination node, the message gets discarded, but source node requesting GET_ALL reponses waits for the response for 4 minutes (default timeout) and then gets an exception failing the HotRod connector. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-65) Local Cache is not updated, case client is started before the server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-65?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-65: ----------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 917787|https://bugzilla.redhat.com/show_bug.cgi?id=917787] from ON_QA to VERIFIED > Local Cache is not updated, case client is started before the server > -------------------------------------------------------------------- > > Key: DROOLS-65 > URL: https://issues.jboss.org/browse/DROOLS-65 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > Local Cache is not updated, case client is started before the server > 1. Start Guvnor > 2. Any regular client application consumes some package with local cache configured (drools.resource.urlcache) > 3. Stop client and server > 4. Restart the client (it will work consuming data from loca cache) > 5. Restart the server and changes a rule from the package used by client application > 6. BUild the package > 7. Local cache still consume the package from the local cache which is never synchronized with the server > It works as expected case only the server is restarted or if server starts before the client. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-65) Local Cache is not updated, case client is started before the server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-65?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-65: ----------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 917787|https://bugzilla.redhat.com/show_bug.cgi?id=917787] Verified on 5.3.1.BRMS-P02. > Local Cache is not updated, case client is started before the server > -------------------------------------------------------------------- > > Key: DROOLS-65 > URL: https://issues.jboss.org/browse/DROOLS-65 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > Local Cache is not updated, case client is started before the server > 1. Start Guvnor > 2. Any regular client application consumes some package with local cache configured (drools.resource.urlcache) > 3. Stop client and server > 4. Restart the client (it will work consuming data from loca cache) > 5. Restart the server and changes a rule from the package used by client application > 6. BUild the package > 7. Local cache still consume the package from the local cache which is never synchronized with the server > It works as expected case only the server is restarted or if server starts before the client. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-5970?page=com.atlassian.jira.plugin.s... ] Stan Silvert commented on AS7-5970: ----------------------------------- Are you guys satisfied that this is fixed now that JAVASERVERFACES-2609 is done? Upstream fix should be integrated now. Can we close this? > RichFaces Showcase portlet is unable to switch skins > ---------------------------------------------------- > > Key: AS7-5970 > URL: https://issues.jboss.org/browse/AS7-5970 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ken Finnigan > Assignee: Stan Silvert > > The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time: > {noformat} > Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444 > at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1] > {noformat} > This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request. > This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8861) JSF Flash doesn't return data in the right order

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8861?page=com.atlassian.jira.plugin.... ] Stan Silvert resolved JBAS-8861. -------------------------------- Resolution: Out of Date > JSF Flash doesn't return data in the right order > ------------------------------------------------ > > Key: JBAS-8861 > URL: https://issues.jboss.org/browse/JBAS-8861 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 6.0.0.Final > Environment: Redhat Linux 5.5 > Reporter: Jboss fan99 > Assignee: Stan Silvert > Fix For: No Release > > Attachments: login.xhtml, LoginBackingBean.java, Referer.xhtml > > > Data stored in JSF flash during a request is not returned in the next request. It's returned during the 3rd request. I have a very simple test to verify this behavior. > LoginBackingBean has two methods which are called in 2 subsequent requests. Variable kept in flash memory during request 1 doesn't return in request 2 but in request 3. > 3 small files required to reproduce are attached. First referer.xhtml should be opened in a JSF app, then its login button calls doLogin method and takes you to Login.xhtml file. Now "Simulate Login" button need to be clicked twice to get the variable. -- 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013