January 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-690) ObjectStoreTypeManager is not threadsafe or typesafe

by Jonathan Halliday (JIRA)

ObjectStoreTypeManager is not threadsafe or typesafe ---------------------------------------------------- Key: JBTM-690 URL: https://jira.jboss.org/jira/browse/JBTM-690 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.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

[JBoss JIRA] Created: (JBTM-687) use maven for 3rd party dependencies

by Jonathan Halliday (JIRA)

use maven for 3rd party dependencies ------------------------------------ Key: JBTM-687 URL: https://jira.jboss.org/jira/browse/JBTM-687 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 Dependencies are either checked into our svn or pulled in via JBOSS_HOME env var. We should support using maven to resolve these instead. -- 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-691) upgrade jacorb to 2.3.1.jbosspatch1

by Jonathan Halliday (JIRA)

upgrade jacorb to 2.3.1.jbosspatch1 ----------------------------------- Key: JBTM-691 URL: https://jira.jboss.org/jira/browse/JBTM-691 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System, JTS Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 We should use the same JacORB version as the AS we are aiming to run with. -- 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-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-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-693) Object Store Browser mbean does not initialise properly

by Michael Musgrove (JIRA)

Object Store Browser mbean does not initialise properly ------------------------------------------------------- Key: JBTM-693 URL: https://jira.jboss.org/jira/browse/JBTM-693 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.9.0 Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 4.10.0 The default com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBean does not initialise itself properly when running in the AS causing a null pointer reference when displaying the bean in a JMX client. Also the need for the jmxEnabled property of ObjectStoreEnvironmentBean is superfluous. See workaround for how to initialise the bean via transaction-jboss-beans.xml. -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2010