February 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-676) remove direct access to ResourceBundle in *Logger classes

by Jonathan Halliday (JIRA)

remove direct access to ResourceBundle in *Logger classes --------------------------------------------------------- Key: JBTM-676 URL: https://jira.jboss.org/jira/browse/JBTM-676 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 The per-module loggers should not allow code to directly access the ResourceBundle. Instead of fooLogger.messages.getString("key") users should call fooLogger.loggeri18n.getString("key") which allows the Logi18n impl to e.g. provide a default key in key not found situations instead of falling over horribly. It also allows for more flexible ResourceBundle handling implementation because it's abstracted via the Logi18n. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-680) refactor module logger initialization

by Jonathan Halliday (JIRA)

refactor module logger initialization ------------------------------------- Key: JBTM-680 URL: https://jira.jboss.org/jira/browse/JBTM-680 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 Each module has a logger class (e.g. jdbcLogger) and each of these has a very similar cut-n-paste static init block to set up the logging. Parametrize this code, move it to LogFactory and have the logger's static block call it instead to reduce duplication and provide a single point of control. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-667) Hibernate exception stack is overridden by SetRollbackOnly

by Terry Xie (JIRA)

Hibernate exception stack is overridden by SetRollbackOnly ---------------------------------------------------------- Key: JBTM-667 URL: https://jira.jboss.org/jira/browse/JBTM-667 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.6.0 Environment: OS: windows XP. Intel CPU Reporter: Terry Xie The fix in https://jira.jboss.org/jira/browse/JBTM-66 makes the hibernate persistence exception lost in exception stack. For example, say there is a duplicate data constraint violation, hibernate entity manager calls calls transaction manager setRollbackOnly . However setRollbackOnly in TransactionImple.java sets the _rollbackOnlyCallerStacktrace which will be thrown as the exception cause later instead of the hibernate exception source. This makes the hibernate persistence exception unable to propagate to jboss clients. In this case, it is much more useful for hibernate exception information to be displayed to clients instead of the setRollbackOnly stack. The method in TransactionImple.java which throws the rollbackOnlyCallerStacktrace instead of _theTransaction.getDeferredThrowable() protected void commitAndDisassociate() throws javax.transaction.RollbackException, javax.transaction.HeuristicMixedException, javax.transaction.HeuristicRollbackException, java.lang.SecurityException, javax.transaction.SystemException, java.lang.IllegalStateException { . . . if(_rollbackOnlyCallerStacktrace != null) { // we rolled back beacuse the user explicitly told us not to commit. Attach the trace of who did that for debug: rollbackException.initCause(_rollbackOnlyCallerStacktrace); } else if(_theTransaction.getDeferredThrowable() != null) { // we tried to commit but it went wrong - attach the reason for debug: rollbackException.initCause(_theTransaction.getDeferredThrowable()); } Here should be the change related to issue JBTM-66 : http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbosstm/trunk/Arjuna... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-675) support i18n enabled loggers directly in CLF

by Jonathan Halliday (JIRA)

support i18n enabled loggers directly in CLF -------------------------------------------- Key: JBTM-675 URL: https://jira.jboss.org/jira/browse/JBTM-675 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Common Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 CLF was designed at a time when no 3rd party logging framework supported i18n, so it is structured such that the CLF always does the i18n and passes the processed message to the underlying log impl. These days some 3rd party loggers do i18n, so it would be nice if we could delegate message processing to them. This will require a bit of cleanup (e.g. remove multiple message bundles per logger requirement, which they typically don't support, see JBTM-674) and then a new factory arrangement so it can be configured and used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-674) decouple jta/jtax logging

by Jonathan Halliday (JIRA)

decouple jta/jtax logging ------------------------- Key: JBTM-674 URL: https://jira.jboss.org/jira/browse/JBTM-674 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA, JTS Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 The jtax code uses the jta module logger rather than having its own, unlike all the other modules. This requires the logging system to jump through hoops to manage the associated resource bundles properly. It's the only use case for such functionality in the logging layer. Requiring the log framework to support this corner case limits our ability to plug in alternative logging impls. It's also unnecessary and potentially undesirable. So, add a jtaxLogger and change the module log statements to use it. Then we can clean up CLF and logging initialization a bit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-703) AT and BA Participant engines are changing state too early at PREPARE/COMPLETE

by Andrew Dinn (JIRA)

AT and BA Participant engines are changing state too early at PREPARE/COMPLETE ------------------------------------------------------------------------------ Key: JBTM-703 URL: https://jira.jboss.org/jira/browse/JBTM-703 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.9.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.10.0 The AT participant engine which handles a prepare request from the coordinator is changing state fro PREPARING to PREPARED before writing the AT participant log record to disk. The writing thread will not post PREPARED to the coordinator until it has completed the write. However, if the write takes a long time then a resend of PREPARE will be returned result PREPARED before the write has actually completed. The state transition to PREPARED should only occur once the log record write is completed. The same problem affects the BA participants when making the transition from state CIMPLETING to COMPLETED. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-689) Register response interop issue

by Guzm?n Llamb?as (JIRA)

Register response interop issue ------------------------------- Key: JBTM-689 URL: https://jira.jboss.org/jira/browse/JBTM-689 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: TxBridge Affects Versions: 4.7.0 Environment: JDK 5 update 21, JBoss AS 5.1.0 GA, JBoss Web Services - Native 3.1.2 GA, JBoss Transactions 4.7 GA, Windows XP Reporter: Guzm?n Llamb?as Wrong registerResponse action message breaks interoperability. See http://community.jboss.org/message/522118#522118 for more details -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-704) SubordinateATCoordinator is not deleting entries from its recovered coordinator list correctly

by Andrew Dinn (JIRA)

SubordinateATCoordinator is not deleting entries from its recovered coordinator list correctly ---------------------------------------------------------------------------------------------- Key: JBTM-704 URL: https://jira.jboss.org/jira/browse/JBTM-704 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.9.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.10.0 SubordinateATCoordinator uses a put or null to delete hashmap entries where it should be doing a remove. This is a prolme because it means method listRecoveredCoordinators can hand out a list containing null pointers which makes the recovery code throw a NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-701) TwoPhaseCoordinator remembering parent for NTLA when it should ignore it

by Mark Little (JIRA)

TwoPhaseCoordinator remembering parent for NTLA when it should ignore it ------------------------------------------------------------------------ Key: JBTM-701 URL: https://jira.jboss.org/jira/browse/JBTM-701 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.9.0 Reporter: Mark Little Assignee: Mark Little Fix For: 4.10.0 Nested top level actions have no parents, but TwoPhaseCoordinator was conveniently remembering them, meaning they were nested transactions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-697) TransactionReaper i18n msg format typo

by Jonathan Halliday (JIRA)

TransactionReaper i18n msg format typo -------------------------------------- Key: JBTM-697 URL: https://jira.jboss.org/jira/browse/JBTM-697 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.6.1.CP04, 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Priority: Minor Fix For: 4.10.0, 4.6.1.CP05 TransactionReaper::check worker zombie count {0] exceeds specified limit should be {0} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2010