March 2008 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-351) fix JBossWorkManager timeout

by Jonathan Halliday (JIRA)

fix JBossWorkManager timeout ---------------------------- Key: JBTM-351 URL: http://jira.jboss.com/jira/browse/JBTM-351 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.3.0.GA Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.4.CR1 The fix for JBTM-274 was applied correctly to the 4.2.3.SP branch but is incorrect on trunk i.e. 4.3.GA. Fix for future releases i.e. 4.4.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

16 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-345) support dynamic (un)registration of recovery modules

by Jonathan Halliday (JIRA)

support dynamic (un)registration of recovery modules ---------------------------------------------------- Key: JBTM-345 URL: http://jira.jboss.com/jira/browse/JBTM-345 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.3.0.GA Reporter: Jonathan Halliday Assigned To: Andrew Dinn Fix For: 4.4.CR1 XTS will be deployed into JBossAS as a .sar and may be deployed and undeployed over the lifetime of the AS instance. The recovery code is always resident in JBossAS, it starts as part of the transaction service. Thus it needs to be able to support XTS registering and unregistering a recovery module for XTS transactions whilst the system is running. Right now recovery modules must be in the jbossjt(a|s)-properties.xml file and are read at startup only. Allow them to be registered and unregistered programatically also. May need fixes for concurrency control, as the list of registered modules is iterated during recovery passes and concurrent modifications are a Bad Thing. -- 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

16 years, 8 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBTM-174) JTA 1.1 support

by Jonathan Halliday (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-174?page=all ] Jonathan Halliday updated JBTM-174: ----------------------------------- Fix Version/s: 4.4.CR1 (was: 4.4) > JTA 1.1 support > --------------- > > Key: JBTM-174 > URL: http://jira.jboss.com/jira/browse/JBTM-174 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation, JTA Implementation, JTS Implementation > Affects Versions: 4.2.2 > Reporter: Mark Little > Assigned To: Jonathan Halliday > Fix For: 4.4.CR1 > > Time Spent: 3 days > Remaining Estimate: 0 minutes > -- 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

16 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-325) Reconcile conflicting overrides of commons-logging Log4JLogger

by Brian Stansberry (JIRA)

Reconcile conflicting overrides of commons-logging Log4JLogger -------------------------------------------------------------- Key: JBTM-325 URL: http://jira.jboss.com/jira/browse/JBTM-325 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.BETA2 Reporter: Brian Stansberry As part of the fix for JBTM-20, JBossTS instructs Jakarta Commons Logging to use com.arjuna.common.internal.util.logging.jakarta.Log4JLogger as its implementation of the JCL Log interface. This supersedes an alternate override of the default JCL behavior that JBoss AS had in place. The AS is using a special forked version of JCL 1.1.0 known as 1.1.0.jboss. The fork involves changing the org.apache.commons.logging.Log4JLogger class to better support use of separate log4j subsystems between different deployments. We need to reconcile these two conflicting overrides of the default JCL behavior and make sure the goals of each are fulfilled. At the moment, I'm aware of two things the AS fork was doing that the com.arjuna version is not: 1) Support for trace level logging -- the com.arjuna class seems to be based on older code and maps trace to debug. 2) Support for not binding of org.apache.log4j classes, using the TCCL to load the log4j classes when a Log4JLogger instance is created and using reflection to invoke upon them. The AS fork isn't doing any of the i18n stuff that AIUI the JBossTS version does. The source for the AS fork of JCL can be found at: 1) https://svn.jboss.org/repos/repository.jboss.org/apache-logging/1.1.0.jbo... 2) cvs -d:ext:starksm@cvs.forge.jboss.com:/cvsroot/jboss co apache CVS tag for the 1.1.0.jboss release is JBoss_Apache_Common_Logging_1_1_0 -- 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

16 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-339) Revive unit tests in WS-T code

by Andrew Dinn (JIRA)

Revive unit tests in WS-T code ------------------------------ Key: JBTM-339 URL: http://jira.jboss.com/jira/browse/JBTM-339 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.3.0.BETA2 Reporter: Andrew Dinn Assigned To: Andrew Dinn Fix For: 4.3.0.BETA3 -- 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

16 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-344) doc updates for 4.3

by Jonathan Halliday (JIRA)

doc updates for 4.3 ------------------- Key: JBTM-344 URL: http://jira.jboss.com/jira/browse/JBTM-344 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.3.0.BETA2 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.3.0.GA Update .doc files, particularly release notes, for 4.3.GA. Regenerate .pdf files to ensure they are in sync. -- 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

16 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-320) jta/jtax cross-package logging broken

by Jonathan Halliday (JIRA)

jta/jtax cross-package logging broken ------------------------------------- Key: JBTM-320 URL: http://jira.jboss.com/jira/browse/JBTM-320 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.3.0.BETA2, 4.2.3.SP6 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP8, 4.3.0.BETA3 Some classes in jtax i.e. the JTS based JTA implementation, use logging support from the jta rather than jtax pakage. This is the only instance of cross-package logging in the codebase. This is supported by the LoggerSetup helper class, which merges the jtax log messages properties file into the jta logger using addResourceBundle. That means that jtax code can call e.g. jtaLogger.loggerI18N.warn("com.arjuna.ats.internal.jta.transaction.jts.syncproblem"); and the message key will get resolved correctly. jtaLogger.logger.* is not internationalized i.e. does not use resource bundles, so it's fine too. The problem comes with jtax code's use of e.g. jtaLogger.logMesg.getString("com.arjuna.ats.internal.jta.transaction.jts.subordinate.invalidstate") as is found in many new Exception(...) type statements and elsewhere. Since this code bypasses the loggerI18N and goes direct to the un-merged message bundle, it can resolve only jta keys, not jtax ones. Because it's used mostly in exception handlers, the problem goes unnoticed until something breaks, at which point you fail to get a useful error message. -- 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

16 years, 8 months

1
3
0 / 0

[JBoss JIRA] Closed: (JBTM-16) JBossWS support

by Andrew Dinn (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-16?page=all ] Andrew Dinn closed JBTM-16. --------------------------- Resolution: Done done the demo, XTS guide and trail map > JBossWS support > --------------- > > Key: JBTM-16 > URL: http://jira.jboss.com/jira/browse/JBTM-16 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: WS-T Implementation > Reporter: Mark Little > Assigned To: Andrew Dinn > Priority: Blocker > Fix For: 4.4 > > > After the initial release of the newly integrated Arjuna Transaction Service, ensure support for JBossWS. -- 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

16 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-343) Oracle (version?) requires forget (rollback?) to be called on heuristic rollback during end

by Mark Little (JIRA)

Oracle (version?) requires forget (rollback?) to be called on heuristic rollback during end ------------------------------------------------------------------------------------------- Key: JBTM-343 URL: http://jira.jboss.com/jira/browse/JBTM-343 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 -- 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

16 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-278) XAResource.end error may not cause rollback

by Jonathan Halliday (JIRA)

XAResource.end error may not cause rollback ------------------------------------------- Key: JBTM-278 URL: http://jira.jboss.com/jira/browse/JBTM-278 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2.3.SP5 Reporter: Jonathan Halliday Assigned To: Mark Little Fix For: 4.4 An XAResource.end call may return an XA_RB* error. In such case, the resource should (but currently does not) still get rollback called on it too. Update XAResourceRecord.java to fix. -- 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

16 years, 8 months

2
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2008