July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1530) Creating a portal object hides another object

by Thomas Heute (JIRA)

Creating a portal object hides another object --------------------------------------------- Key: JBPORTAL-1530 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1530 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Admin Affects Versions: 2.6 Final Reporter: Thomas Heute Fix For: 2.6.1 Final, 2.8 Final When the user creates a new object, another object is hidden (the same amount of pages, or portals are displayed before and after adding the object). -- 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-688) Manual and user Guide for BRMS version 1

by Michael Neale (JIRA)

Manual and user Guide for BRMS version 1 ---------------------------------------- Key: JBRULES-688 URL: http://jira.jboss.com/jira/browse/JBRULES-688 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale Fix For: 3.1-m2 -- 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

17 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1048) TreeCache registers channel in JMX if it doesn't get it from ChannelFactory

by Brian Stansberry (JIRA)

TreeCache registers channel in JMX if it doesn't get it from ChannelFactory --------------------------------------------------------------------------- Key: JBCACHE-1048 URL: http://jira.jboss.com/jira/browse/JBCACHE-1048 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 1.4.1.SP4 The JON team wants to be able to monitor all channels in the AS via JMX (see JGRP-207). But, channels only get registered in JMX if they are created via a call to JChannelFactory.createMultiplexerChannel(). AS 4.2 currently doesn't use the multiplexer, so none of the JBC-created channels are created this way. Workaround suggestion is to have JBC register the channel it creates via a call to org.jgroups.jmx.JmxConfigurator.registerChannel(). An unregisterChannel call would have to be added any time the channel is closed as well. I marked this for SP4 but the real intent is it would be included in a CP release for AS 4.2. -- 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

17 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1010) Modify 2nd level entity cache impls to not leak JBoss Cache exceptions

by Brian Stansberry (JIRA)

Modify 2nd level entity cache impls to not leak JBoss Cache exceptions ----------------------------------------------------------------------- Key: EJBTHREE-1010 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1010 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: EJB 3.0 RC11 - FD Modify JBCCache and OptimisticJBCCache so JBC exception types don't propagate to the client via the exception chaining mechanism. Clients likely won't have JBC classes on the classpath. See StatefulTreeCache.convertToRuntimeException for a similar handling for SFSBs. -- 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4535) Convert to the notification API introduced in 2.0.0.CR3

by Brian Stansberry (JIRA)

Convert to the notification API introduced in 2.0.0.CR3 ------------------------------------------------------- Key: JBAS-4535 URL: http://jira.jboss.com/jira/browse/JBAS-4535 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, EJB3, Test Suite, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 The old CacheListener interface has been replaced by use of annotated callback methods. -- 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4544) Add setServiceHAName to HAServiceMBeanSupport

by Brian Stansberry (JIRA)

Add setServiceHAName to HAServiceMBeanSupport --------------------------------------------- Key: JBAS-4544 URL: http://jira.jboss.com/jira/browse/JBAS-4544 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta3 Currently, getServiceHAName() returns the ObjectName of the service, unless you override the method. This helps tie the class to JMX. Add a setter for the property as a step towar "POJOizing" this class. -- 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

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-847) Continously updating facts and firing rules leads to OutOfMemoryException

by Lars Ivar Igesund (JIRA)

Continously updating facts and firing rules leads to OutOfMemoryException ------------------------------------------------------------------------- Key: JBRULES-847 URL: http://jira.jboss.com/jira/browse/JBRULES-847 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.5 Environment: Linux, Eclipse 3.2, JDK 1.6, JBoss Rules from Maven rep Reporter: Lars Ivar Igesund Assigned To: Mark Proctor The rules at the end are checked against two facts of type TextileUser. The facts are true for the first rule when asserted. The action modfies the facts to make them true for the other rule, which again make the facts true for the first rule, creating an infinite loop. On my setup, this leads to an OutOfMemoryException after about 40 seconds. Increasing the number of facts to 100 didn't change this. -------------------- rule "User needs textiles" when #conditions tu: TextileUser(wantTextile==true) then #actions tu.collectTextiles(); modify( tu ); end rule "User has dirty textiles" #include attributes such as "salience" here... when #conditions tu: TextileUser(hasDirtyTextiles == true); then #actions tu.returnTextiles(); modify ( tu ); end -- 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

17 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-570) Do we need acceptReliableMessages flag on the channel?

by Tim Fox (JIRA)

Do we need acceptReliableMessages flag on the channel? ------------------------------------------------------ Key: JBMESSAGING-570 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-570 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Alpha1 Reporter: Tim Fox Priority: Minor Fix For: 1.2.0.Beta1 Is there a real use case for ever setting this to false? I can't think of one in a typical messaging application. If not, we should consider removing this flag. -- 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

17 years, 2 months

4
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-894) Combine postoffice and clustered post office

by Tim Fox (JIRA)

Combine postoffice and clustered post office -------------------------------------------- Key: JBMESSAGING-894 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-894 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.CR1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 We should combine clustered and non clustered post office into one single post office that handles both clusterd and non clustered bindings. This means we can have a single persistence manager config too, and remove all that nasty condition code like If (queue.isClustered()) { postOffice.unbind(); } else { postOffice.clusteredUnbind() } etc which is currently ugly and prone to error -- 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

17 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-883) Bug in failover with multiple consumers on same queue

by Tim Fox (JIRA)

Bug in failover with multiple consumers on same queue ----------------------------------------------------- Key: JBMESSAGING-883 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-883 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.CR1 Reporter: Tim Fox Assigned To: Tim Fox Priority: Blocker Fix For: 1.2.0.GA If you have two connections with a consumer each on the same queue, and one of the consumers has consumed a message transactionally but not committed it. Then when failover occurs, if the second connection fails over first then it might "grab" the message before session::recoverDeliveries kicks in for the other connection. This means the message can get delivered more than once. -- 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

17 years, 2 months

3
21
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007