February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-654) Create asset of various types for Package Manager

by Michael Neale (JIRA)

Create asset of various types for Package Manager ------------------------------------------------- Key: JBRULES-654 URL: http://jira.jboss.com/jira/browse/JBRULES-654 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-659) Support for recursive primitive arrays

by Frederic Burlet (JIRA)

Support for recursive primitive arrays -------------------------------------- Key: JBRULES-659 URL: http://jira.jboss.com/jira/browse/JBRULES-659 Project: JBoss Rules Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 3.1-m1 Reporter: Frederic Burlet Assigned To: Mark Proctor Attachments: patch_recursive_primitive_array.patch This is a patch to support recursive primitive arrays (arrays of arrays of arrays...) in functions and attribute of facts. This patch contains the updated code and a test case. It has been built against the trunk, revision #9417. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4025) failing org.jboss.test.web.test.ssl.SSLUnitTestCase

by Dimitris Andreadis (JIRA)

failing org.jboss.test.web.test.ssl.SSLUnitTestCase --------------------------------------------------- Key: JBAS-4025 URL: http://jira.jboss.com/jira/browse/JBAS-4025 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Environment: Java Version 1.5.0_10 Java Vendor Sun Microsystems Inc. Java VM Name Java HotSpot(TM) Server VM Java VM Version 1.5.0_10-b03 Java VM Info mixed mode OS Name Linux OS Version 2.6.9-42.0.2.ELsmp OS Arch i386 Reporter: Dimitris Andreadis Assigned To: Stan Silvert Priority: Critical Fix For: JBossAS-4.2.0.CR1 It seems the SSL connector of jboss-web is not configured properly? In fact, a lot of other ssl security tests seem to fail. Can you take a look Stan? unknown Error Timeout occurred junit.framework.AssertionFailedError: Timeout occurred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1249) optimize number of DB calls when a simple portlet page is hit

by Prabhat Jha (JIRA)

optimize number of DB calls when a simple portlet page is hit ------------------------------------------------------------- Key: JBPORTAL-1249 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1249 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha2 Reporter: Prabhat Jha Assigned To: Julien Viet Assuming that following queries have already been optimized, can we reduce these DB calls and queries which are being made for every hit to the page? The URL that gets hit is http://localhost:8080/portal/portal/default/NullPortletPage 1. I see "[org.hibernate.jdbc.ConnectionManager] opening JDBC connection" getting printed 35 times. 2. This query is made 27 times. select objectnode0_.PK as PK56_1_, objectnode0_.PATH as PATH56_1_, objectnode0_.NAME as NAME56_1_, objectnode0_.PARENT_KEY as PARENT4_56_1_, securityco1_.NODE_KEY as NODE3_3_, securityco1_.PK as PK3_, securityco1_.ROLE as ROLE3_, securityco1_.PK as PK65_0_, securityco1_.ROLE as ROLE65_0_, securityco1_.NODE_KEY as NODE3_65_0_, actions2_.PK as PK4_, actions2_.ACTIONS as ACTIONS4_ from JBP_OBJECT_NODE objectnode0_ left outer join JBP_OBJECT_NODE_SEC securityco1_ on objectnode0_.PK=securityco1_.NODE_KEY left outer join JBP_OBJECT_NODE_SEC_ACTIONS actions2_ on securityco1_.PK=actions2_.PK where objectnode0_.PK=? 3. This query is made 8 times: select portalobje0_.PK as PK57_0_, portalobje0_.LISTENER as LISTENER57_0_, portalobje0_4_.INSTANCE_REF as INSTANCE2_64_0_, case when portalobje0_1_.PK is not null then 1 when portalobje0_2_.PK is not null then 2 when portalobje0_3_.PK is not null then 3 when portalobje0_4_.PK is not null then 4 when portalobje0_.PK is not null then 0 end as clazz_0_, declaredpr1_.OBJECT_KEY as OBJECT1_2_, declaredpr1_.jbp_VALUE as jbp2_2_, declaredpr1_.NAME as NAME2_, modes2_.PK as PK3_, modes2_.name as name3_, windowstat3_.PK as PK4_, windowstat3_.name as name4_ from JBP_PORTAL_OBJECT portalobje0_ left outer join JBP_CONTEXT portalobje0_1_ on portalobje0_.PK=portalobje0_1_.PK left outer join JBP_PORTAL portalobje0_2_ on portalobje0_.PK=portalobje0_2_.PK left outer join JBP_PAGE portalobje0_3_ on portalobje0_.PK=portalobje0_3_.PK left outer join JBP_WINDOW portalobje0_4_ on portalobje0_.PK=portalobje0_4_.PK left outer join JBP_PORTAL_OBJECT_PROPS declaredpr1_ on portalobje0_.PK=declaredpr1_.OBJECT_KEY left outer join JBP_PORTAL_MODE modes2_ on portalobje0_.PK=modes2_.PK left outer join JBP_PORTAL_WINDOW_STATE windowstat3_ on portalobje0_.PK=windowstat3_.PK where portalobje0_.PK=? 4. select children0_.PARENT_KEY as PARENT4_1_, children0_.PK as PK1_, children0_.NAME as NAME1_, children0_.PK as PK56_0_, children0_.PATH as PATH56_0_, children0_.NAME as NAME56_0_, children0_.PARENT_KEY as PARENT4_56_0_ from JBP_OBJECT_NODE children0_ where children0_.PARENT_KEY=? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-826) Using Pre Configure clientIDs will invalidate the usage of a simple createConnection

by Clebert Suconic (JIRA)

Using Pre Configure clientIDs will invalidate the usage of a simple createConnection ------------------------------------------------------------------------------------ Key: JBMESSAGING-826 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-826 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta2, 1.2.0.Beta1 Reporter: Clebert Suconic Assigned To: Clebert Suconic Priority: Blocker Fix For: 1.2.0.CR1 Using a cf.createConnection(User,Password) for a user with a pre-configured clientID will invalidate the use of cf.createConnection(); Something is dirty on the session keeping the clientID from the previous invocation. DuplicateClientIDTest::testNotDuplicateClientID fails for this. This is the failing scenario: c0 = cf.createConnection("dilbert", "dogbert"); c1 = cf.createConnection(); c1 can't be created as the CF will use the same pre-configured ID from dilbert. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (JBAS-4090) Race condition in Connection.close() can deadlock the JBossMQ's ping thread.

by Adrian Brock (JIRA)

Race condition in Connection.close() can deadlock the JBossMQ's ping thread. ---------------------------------------------------------------------------- Key: JBAS-4090 URL: http://jira.jboss.com/jira/browse/JBAS-4090 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1 Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-4.0.5.SP1 There is a race condition between the JBossMQ ping thread and connection.close() that can cause the ping thread to become deadlocked. Besides meaning that the ping stops working so broken connections are not detected, this can also evenutally lead to a memory leak. The problem occurs when the connection.close() requests to cancel the ping for that connection, and then aquires the semaphore to make sure the ping has stopped working. Just at that moment, the ping was scheduled to run and tries to aquire the semaphore (with no timeout), but it never can because the connection.close() has permenantly aquired it. The obvious fix is to include a timeout in the ping task's such that when it fails to acquire the semaphore it can assume that the connection was closed and return immediately. Additionally, checking the "closing" flag should also avoid even trying to acquire the semaphore when the connection is being closed (in most cases). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-827) ACK fails during failover on transacted session

by Clebert Suconic (JIRA)

ACK fails during failover on transacted session ----------------------------------------------- Key: JBMESSAGING-827 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-827 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Priority: Blocker Fix For: 1.2.0.CR1 ServerSessionEndpoint::acknowledgeTransactionally is checking for the existence of ACKs. we have agreed we could ignore case ACK was not found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-976) Correct Javadoc to reflect LockParentForChildInsertRemove default is false

by Brian Stansberry (JIRA)

Correct Javadoc to reflect LockParentForChildInsertRemove default is false -------------------------------------------------------------------------- Key: JBCACHE-976 URL: http://jira.jboss.com/jira/browse/JBCACHE-976 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 1.4.1.SP2 The default value for LockParentForChildInsertRemove got changed after JBCACHE-955 was closed but the javadoc comments were not updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-649) Move ClusterRequest and its subclasses to its own package

by Clebert Suconic (JIRA)

Move ClusterRequest and its subclasses to its own package --------------------------------------------------------- Key: JBMESSAGING-649 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-649 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Alpha2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Priority: Optional Fix For: 1.0.2.CR1 I don't see a problem on ClusterRequest and its child classes being public classes. We should move them to a separate package, cleaning postoffice.cluster a little bit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4015) failing org.jboss.test.invokers.test.MultiInvokersUnitTestCase

by Dimitris Andreadis (JIRA)

failing org.jboss.test.invokers.test.MultiInvokersUnitTestCase -------------------------------------------------------------- Key: JBAS-4015 URL: http://jira.jboss.com/jira/browse/JBAS-4015 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Assigned To: Tom Elrod Priority: Critical Fix For: JBossAS-4.2.0.CR1 Testsuite: org.jboss.test.invokers.test.MultiInvokersUnitTestCase Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 3.915 sec Testcase: testMultiInvokers took 1.222 sec Testcase: testClientContainer took 0.14 sec Caused an ERROR $Proxy7 java.lang.ClassCastException: $Proxy7 at org.jboss.test.invokers.test.MultiInvokersUnitTestCase.testClientContainer(MultiInvokersUnitTestCase.java:103) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007