July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2854) Fire local transaction events from the jms resource adapter

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2854?page=all ] Adrian Brock updated JBAS-2854: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Fire local transaction events from the jms resource adapter > ----------------------------------------------------------- > > Key: JBAS-2854 > URL: http://jira.jboss.com/jira/browse/JBAS-2854 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Fix For: JBossAS-4.0.6.CR1 > > > We need to fire local transaction events from the jms resource adapter. > This is not a trivial change since there is currently no easy way for the JmsSession class > to work out when the transaction started and whether it is a local transaction. > There is no explicit start of transaction in JMS. > It probably needs a modfication to getSession() as this is the most obvious point > where work is first done in a new transaction after the commit/rollback on the session. -- 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-2842) Add support for stopping ILs triggering the ExceptionListener

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2842?page=all ] Adrian Brock updated JBAS-2842: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Add support for stopping ILs triggering the ExceptionListener > ------------------------------------------------------------- > > Key: JBAS-2842 > URL: http://jira.jboss.com/jira/browse/JBAS-2842 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Fix For: JBossAS-4.0.6.CR1 > > > As per the super task which is a fix to make sure client exception listeners > get triggered if somebody stops the server, this same behaviour should > occur if somebody just stops the IL. > This involves making each IL keep track of their respective connections. -- 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-2464) Support JMSX properties

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2464?page=all ] Adrian Brock updated JBAS-2464: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Support JMSX properties > ----------------------- > > Key: JBAS-2464 > URL: http://jira.jboss.com/jira/browse/JBAS-2464 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Adrian Brock > Fix For: JBossAS-4.0.6.CR1 > > > Look at supporting other JMSX properties in JBossMQ -- 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-3091) Session recycle bug in org.jboss.jms.asf.StdServerSession

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3091?page=all ] Adrian Brock updated JBAS-3091: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Session recycle bug in org.jboss.jms.asf.StdServerSession > --------------------------------------------------------- > > Key: JBAS-3091 > URL: http://jira.jboss.com/jira/browse/JBAS-3091 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Roland R?z > Fix For: JBossAS-4.0.6.CR1 > > > If a JMS provider throws an unchecked Exception out of Session.run(), the method org.jboss.jms.asf.StdServerSession.run() does recycled the Session without making a rollback on the Session before. If the next message on this recycled Session will be commited the older Message which has been already consumed from the Messaging System before when throwing the Exception will be lost. Because of the Exception this older Message has neither been rollbacked nor committed before. > To avoid this problem a Session.rollback() needs to be called before recycling it in case of any unchecked Exception. (See code snippet below!) > Possible Fix: > public void run() > { > boolean trace = log.isTraceEnabled(); > if (trace) > log.trace("running..."); > try > { > if (xaSession != null) > xaSession.run(); > else > session.run(); > } > // To avoid loosing Messages rollback the Session in case of any Exception from the JMS provider > catch (Throwable e) { > log.error("Exception occured during the Session.run(). Call Session.rollback() before recycling it.", e); > try { > if (xaSession != null) > xaSession.rollback(); > else > session.rollback(); > } > catch (JMSException ex) { > log.error("Exception occured when calling Session.rollback()", e); > } > } > finally > { > if (trace) > log.trace("recycling..."); > > recycle(); > if (trace) > log.trace("finished run"); > } > } -- 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-3352) Provide better validation of the redelivery parameters on JBossMQ queues and topics

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3352?page=all ] Adrian Brock updated JBAS-3352: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Provide better validation of the redelivery parameters on JBossMQ queues and topics > ----------------------------------------------------------------------------------- > > Key: JBAS-3352 > URL: http://jira.jboss.com/jira/browse/JBAS-3352 > 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 > Fix For: JBossAS-4.0.6.CR1 > > > The JBossMQ Queues and Topics have parameters for redelivery delay and limit. > Both accept any value. There should be validation that errors attempts to use negative values. -- 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-3221) JMSContainerInvokerQueueMessageDrivenUnitTestCase failures

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3221?page=all ] Adrian Brock updated JBAS-3221: ------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > JMSContainerInvokerQueueMessageDrivenUnitTestCase failures > ---------------------------------------------------------- > > Key: JBAS-3221 > URL: http://jira.jboss.com/jira/browse/JBAS-3221 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service, Test Suite > Affects Versions: JBossAS-4.0.4.GA > Reporter: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure: > <testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891"> > <error message="Wrong number of messages, expected=2 > got=1" type="java.lang.Exception">java.lang.Exception: Wrong > number of messages, expected=2 got=1 > at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46) > at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112) > at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67) > From Adrian: > The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail. > The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy. > The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits. > In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state. > e.g. The jms queue is empty or a thread pool has no scheduled work, etc. -- 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-3131) Extension-List MANIFEST attribute not honored during deployment of an EAR

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3131?page=all ] Dimitris Andreadis updated JBAS-3131: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Extension-List MANIFEST attribute not honored during deployment of an EAR > ------------------------------------------------------------------------- > > Key: JBAS-3131 > URL: http://jira.jboss.com/jira/browse/JBAS-3131 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Windows XP SP2, JDK 1.5.0_06 > Reporter: Alexander Sack > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > If a JAR within an EAR specifies an Extension-List MANIFEST attribute, the EAR deployer does not honor it. I have a library, my.jar, that gets deployed that specifies an Extension-Name and Implementation-Version. If any of my jars within an EAR references this library, JBoss ignores the Extension-List attribute. The use of the Extension-List MANIFEST attribute is part of the core J2EE 1.4 spec and the EAR deployment should fail if the Extension-List library is not found (or if it is found and the <name>-Implementatino-Version does not meet the minimal requirements. -- 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-1853) Better isolate the server log4j usage

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1853?page=all ] Dimitris Andreadis updated JBAS-1853: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration] (was: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)]) > Better isolate the server log4j usage > ------------------------------------- > > Key: JBAS-1853 > URL: http://jira.jboss.com/jira/browse/JBAS-1853 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Logging > Affects Versions: JBossAS-4.0.2 Final > Reporter: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > The default logging configuration location mechanism of log4j will find the server conf/log4j.xml file. One simple isolation step is to rename this file conf/jboss-log4j.xml since we do not rely on the default logging configuration location mechanism of log4j. The next level of isolation is to actually create a unique LoggerRepository for use by the jboss Logger in the Log4jService. The concern is that components like jgroups, hibernate, tomcat, etc. using commons logging will fail to pickup the Log4jService LoggerRepository. We probably need to configure commons logging as well from the Log4jService with a flag that can disable this. -- 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-2652) Need tests validating the expected JSR77 names of components

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2652?page=all ] Dimitris Andreadis updated JBAS-2652: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Need tests validating the expected JSR77 names of components > ------------------------------------------------------------ > > Key: JBAS-2652 > URL: http://jira.jboss.com/jira/browse/JBAS-2652 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Management services > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Assigned To: Dimitris Andreadis > Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1 > > > We need to update the jsr77 tests to validate that the jsr77 names of the various component deployment types are as expected for the various project uses. -- 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] Commented: (JBAS-3142) Add UnifiedInvoker (JBSer and JavaSer) into Version MatrixTestSuite

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3142?page=comments#action_12340004 ] Dimitris Andreadis commented on JBAS-3142: ------------------------------------------ Clebert, will you have this withing the next 2 weeks? > Add UnifiedInvoker (JBSer and JavaSer) into Version MatrixTestSuite > ------------------------------------------------------------------- > > Key: JBAS-3142 > URL: http://jira.jboss.com/jira/browse/JBAS-3142 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Clebert Suconic > Assigned To: Clebert Suconic > Fix For: JBossAS-4.0.5.CR1 > > -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006