September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBIDE-354) 16x16 and 32x32 icon for JBossIDE

by Marshall Culpepper (JIRA)

16x16 and 32x32 icon for JBossIDE --------------------------------- Key: JBIDE-354 URL: http://jira.jboss.com/jira/browse/JBIDE-354 Project: JBoss IDE Issue Type: Feature Request Reporter: Marshall Culpepper Assigned To: James Cobb We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =) -- 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, 10 months

3
6
0 / 0

[JBoss JIRA] Closed: (JBCACHE-254) Provide an efficient way to relocate a child Node

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-254?page=all ] Manik Surtani closed JBCACHE-254. --------------------------------- Fix Version/s: 2.0.0 (was: 2.1.0) Resolution: Done Fixed this in 2.0.0 - a single move() impl. > Provide an efficient way to relocate a child Node > ------------------------------------------------- > > Key: JBCACHE-254 > URL: http://jira.jboss.com/jira/browse/JBCACHE-254 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0 > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.0.0 > > > Can TreeCache provide an efficient to re-locate a child Node say from parent A to parent B? The only problem I see is the associated fqn name. I may need this feature in TreeCacheAop. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-300) move()

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-300?page=all ] Manik Surtani closed JBCACHE-300. --------------------------------- Resolution: Done > move() > ------ > > Key: JBCACHE-300 > URL: http://jira.jboss.com/jira/browse/JBCACHE-300 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Manik Surtani > Priority: Critical > Fix For: 2.0.0 > > > Moves an entire subtree under a different subtree -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-313) MultiplexerTests don't work with TCP configuration

by Bela Ban (JIRA)

MultiplexerTests don't work with TCP configuration -------------------------------------------------- Key: JGRP-313 URL: http://jira.jboss.com/jira/browse/JGRP-313 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 UDP works 100%, however, some of the tests fail with a TCP configuration -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3483) The javadoc relating to StdServerSessionPool pooling parameters is wrong

by Adrian Brock (JIRA)

The javadoc relating to StdServerSessionPool pooling parameters is wrong ------------------------------------------------------------------------ Key: JBAS-3483 URL: http://jira.jboss.com/jira/browse/JBAS-3483 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.4.GA Reporter: Adrian Brock Priority: Minor Fix For: JBossAS-4.0.5.GA The javadoc in the StdServerSessionPool constructor is misleading. It refers to the pool parameters controlling the number of sessions when it primarily controls the number of threads. Only the MaxPoolSize controls the number of sessions which are created at pool construction time. This WIKI page has it correct: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3631) Missing branch in StdServerSession commit logic

by Adrian Brock (JIRA)

Missing branch in StdServerSession commit logic ----------------------------------------------- Key: JBAS-3631 URL: http://jira.jboss.com/jira/browse/JBAS-3631 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.5.CR1 Reporter: Adrian Brock Assigned To: Weston Price Fix For: JBossAS-4.0.5.GA There is a missing branch in the StdServerSession commit logic. In the case where the transaction manager rollsback the transaction early, e.g. JBossTM does this for transaction timeouts, the status will be NO_TRANSACTION (or a heuristic state). The code: // Marked rollback if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK) { if (trace) log.trace(StdServerSession.this + " rolling back JMS transaction tx=" + trans); // actually roll it back tm.rollback(); // NO XASession? then manually rollback. // This is not so good but // it's the best we can do if we have no XASession. if (xaSession == null && serverSessionPool.isTransacted()) { session.rollback(); } } else if (trans.getStatus() == Status.STATUS_ACTIVE) { // Commit tx // This will happen if // a) everything goes well // b) app. exception was thrown if (trace) log.trace(StdServerSession.this + " commiting the JMS transaction tx=" + trans); tm.commit(); // NO XASession? then manually commit. This is not so good but // it's the best we can do if we have no XASession. if (xaSession == null && serverSessionPool.isTransacted()) { session.commit(); } } needs an extra branch: else { if (trace) log.trace(StdServerSession.this + " transaction already ended tx=" + trans); // spend the thread association tm.suspend(); // NO XASession? then manually rollback. // This is not so good but // it's the best we can do if we have no XASession. if (xaSession == null && serverSessionPool.isTransacted()) { session.rollback(); } } -- 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, 10 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter makes unnecessary temporary delete requests

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ] Adrian Brock updated JBAS-1485: ------------------------------- Fix Version/s: (was: JBossAS-4.0.5.GA) > JMS ResourceAdapter makes unnecessary temporary delete requests > --------------------------------------------------------------- > > Key: JBAS-1485 > URL: http://jira.jboss.com/jira/browse/JBAS-1485 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Priority: Optional > > The JMS ResourceAdaptor keeps track of temporaries created on a connection > (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl) > and deletes them. > This is because we cannot expect the real JMS implementation to do this > because the connection is pooled and not closed. > However, if the user is deleting the temporaries themselves > (good practice in terms of resource usage), > the JMS ResourceAdapter does not know about this > and tries to repeat the delete at connection.close(); > Solution: > Add some wrapping processing for the temporary queues and topics > so we can trap temporary.delete(). That way we will know we don't > need to do it on close() > IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will > also need to trap these destinations to do the necessary wrapping/unwrapping. > It is also possible to retrieve a temporary destination with Session.createQueue/Topic. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1908) listMessageCounter issue with JMS subscriptions containing certain message selector characters

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ] Adrian Brock updated JBAS-1908: ------------------------------- Fix Version/s: (was: JBossAS-4.0.5.GA) > listMessageCounter issue with JMS subscriptions containing certain message selector characters > ---------------------------------------------------------------------------------------------- > > Key: JBAS-1908 > URL: http://jira.jboss.com/jira/browse/JBAS-1908 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.2 Final > Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2 > Reporter: Jaco Joubert > Priority: Minor > Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml > > > When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans: > 1. The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException: > Caused by: java.lang.NumberFormatException: For input string: " 'ghi'" > at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) > at java.lang.Integer.parseInt(Integer.java:468) > at java.lang.Integer.parseInt(Integer.java:518) > at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > ... 44 more > This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with > a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case. > 2. The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML > table has some of the selector values populating the counter columns. The problem is because of the same issue as above. > > This can be reproduced by following these steps: > 1. Startup a JBoss4.0.2 with default configuration. > 2. Deploy the attached 'test-topic-service.xml'. This will create a JMS topic called 'counterTestTopic'. > 3. Run the attached client (source included in jar). The only jar needed on classpath is the 'jbossall-client.jar': > java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter > This will do the following: > 3.1. Connect to the JMS server running locally. > 3.2. Create a publisher and durable subscriber on the 'counterTestTopic' already deployed. > The subscriber has a message selector in the format already described > 3.3. Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error. > 3.4. Wait for the client to look at the html table created by the topic in a browser. > 3.5. Remove the subscription and exit. > > Suggested fixes for the problem includes: > 1. Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter. (See MessageCounter.txt attached) > 2. Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method > on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table. > (See the DestinationManager.txt file attached). > 3. Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above. > (See the DestinationMBeanSupport.txt file attached). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1346) JDBC StateManager

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ] Adrian Brock updated JBAS-1346: ------------------------------- Fix Version/s: (was: JBossAS-4.0.5.GA) > JDBC StateManager > ----------------- > > Key: JBAS-1346 > URL: http://jira.jboss.com/jira/browse/JBAS-1346 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final > Reporter: Adrian Brock > Priority: Minor > > The JDBC StateManager should have operations to create/delete users and subscriptions in the > database, just like the old File StateManager did. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-319) -props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml

by Bela Ban (JIRA)

-props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml ------------------------------------------------------------------- Key: JGRP-319 URL: http://jira.jboss.com/jira/browse/JGRP-319 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 If we explicitly define a relative path for a config file, then we must honor it, so find ./udp.xml *before* udp.xml in the classpath -- 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, 10 months

1
1
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 September 2006