October 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-716) Tooling code coverage

by Mark Little (JIRA)

Tooling code coverage --------------------- Key: JBTM-716 URL: https://jira.jboss.org/jira/browse/JBTM-716 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Testing, Tooling, Transaction Core Reporter: Mark Little Assignee: Michael Musgrove Fix For: 4.11.0 Write coverage for everything under the com.arjuna,.ats.arjuna.tools, as these are now the only classes in the arjuna module that have zero coverage. -- 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, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-796) The Object Store Browser Bean does not support all Object Store types

by Michael Musgrove (JIRA)

The Object Store Browser Bean does not support all Object Store types --------------------------------------------------------------------- Key: JBTM-796 URL: https://jira.jboss.org/browse/JBTM-796 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.12.0 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 4.14.0 There is an MBean called ObjStoreBrowserMBean which is responsible for exposing ObjectStore records. The bean only works with file based object stores but it needs to work with all object store types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-599) Synchronization problem in CacheStore

by Andrew Dinn (JIRA)

Synchronization problem in CacheStore ------------------------------------- Key: JBTM-599 URL: https://jira.jboss.org/jira/browse/JBTM-599 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andrew Dinn This bug manifests occasionally when running the CachedTest. The AsyncStore thread suspends inside its run method on a (120 sec) timed wait because the cache is not full. When I managed to catch this case in the debugger I found that there were many writer threads (~30) suspended inside addWork in an untimed wait on the overflow lock. So, these writing threads make no progress for 120 seconds. The AsyncStore thread does notify the object on which the writers are waiting but there is clearly a window where the writers can go to sleep while the cache is full and not get notified when the AsyncStore thread has emptied it. -- 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, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (JBTM-811) Remove/move finalizer from StateManager

by Mark Little (JIRA)

Remove/move finalizer from StateManager --------------------------------------- Key: JBTM-811 URL: https://jira.jboss.org/browse/JBTM-811 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.14.0 Only needed in TXOJ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-812) remove obsolete JDBC3 code

by Jonathan Halliday (JIRA)

remove obsolete JDBC3 code -------------------------- Key: JBTM-812 URL: https://jira.jboss.org/browse/JBTM-812 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JCA Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.14.0 We no longer build on JDK5 so keeping the JDBC3/4 split is a waste of time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-804) BA participant soapFault method log messages say vcancelling instead of compensating

by Andrew Dinn (JIRA)

BA participant soapFault method log messages say vcancelling instead of compensating ------------------------------------------------------------------------------------ Key: JBTM-804 URL: https://jira.jboss.org/browse/JBTM-804 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.6.1.CP08, 4.13.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.14.0, 4.6.1.CP09 When a participant engine receives an invalid state soap fault for a completed participant it automatically compensates the participant. However, the log message says that it is cancelling the participant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-803) The WSDLs of the WS-C services are present both in ws-c11.jar e wstx.jar

by Mauro Molinari (JIRA)

The WSDLs of the WS-C services are present both in ws-c11.jar e wstx.jar ------------------------------------------------------------------------ Key: JBTM-803 URL: https://jira.jboss.org/browse/JBTM-803 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.13.0 Reporter: Mauro Molinari Priority: Minor The WSDLs of the WS-C services (wsat-coordinator-binding and wscoor-activation-binding) are located in two places, in ws-c11.jar but also in wstx.jar. They have been put in the ws-c11 jar so the coordinator service classes (also in this jar) can find them. But also in wstx11.jar so the client classes (also in wstx11.jar) can find them. However, since all the XTS JARs at the moment are needed on each part of the system (Client, Coordinator, Participant), it's useless (and confusing) to have these WSDLs in both places. I personally suggest to keep the ones in ws-c11.jar, so that they are easily recognizable as the counterparts of the WS-T services WSDLs in ws-t11.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-799) Provide a way to configure the WS-C and WS-T service endpoint URLs/paths

by Mauro Molinari (JIRA)

Provide a way to configure the WS-C and WS-T service endpoint URLs/paths ------------------------------------------------------------------------ Key: JBTM-799 URL: https://jira.jboss.org/browse/JBTM-799 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.13.0 Reporter: Mauro Molinari As of now, the paths to get to the exposed service endpoints of the different WS-C and WS-T services is hard coded, based on the JBossAS/JBossWS convention of using the path <war-name>/<service-name> (where <war-name> is the name of the war containing the service). For instance, the ActivationService URL is expected to be http://bindAddress:bindPort/ws-c11/ActivationService. However, if you want to deploy to another environment (for instance: your own web application, running on Tomcat with CXF), you may want (or you may even be forced) to change the endpoint URLs as you like. Since with CXF (and, in general, with JAX-WS) you are free to expose a webservice with the URL you prefer, the best would be to make XTS configurable in this sense. Every component (Client, Participant, Coordinator) should be improved to let the user specify the URL at which he wants to expose the corresponding webservices (i.e.: for WS-AT, it's the CompletionInitiator on the Client, the Participant on the Participant, the Coordinator, CompletionCoordinator, Activation and Registration on the Coordinator). More precisely, since the bindAddress and bindPort are already settable, just the path part should be made configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBTM-800) Recovery manager not initialised when deploying just the Coordinator

by Mauro Molinari (JIRA)

Recovery manager not initialised when deploying just the Coordinator -------------------------------------------------------------------- Key: JBTM-800 URL: https://jira.jboss.org/browse/JBTM-800 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.13.0 Reporter: Mauro Molinari If you deploy just the Coordinator component of XTS and you follow the configuration guidelines, you may be providing just the following recovery manager configuration entries in xts-properties.xml: <entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry> <entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry> However, in this way, after the Coordinator has started, you get the following NullPointerException: Exception in thread "Periodic Recovery" java.lang.NullPointerException at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.processTransactionsStatus(ATCoordinatorRecoveryModule.java:280) at org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule.periodicWorkSecondPass(ATCoordinatorRecoveryModule.java:121) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) This is because the recovery manager is currently initialized by the ATParticipantRecoveryModule, which is expected to be made available just on the Participant component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBTM-798) Package the XTS service and initialisation classes in a JAR, rather than in the SAR

by Mauro Molinari (JIRA)

Package the XTS service and initialisation classes in a JAR, rather than in the SAR ----------------------------------------------------------------------------------- Key: JBTM-798 URL: https://jira.jboss.org/browse/JBTM-798 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.13.0 Reporter: Mauro Molinari As of now, the binary distribution of XTS provides the following classes in jbossxts.sar: org.jboss.jbossts.XTSService org.jboss.jbossts.XTSServiceMBean org.jboss.jbossts.initialisation.* org.jboss.jbossts.logging.* As discussed in the forum, in order to make XTS easily deployable outside JBossAS it would be convenient to move these classes into one of the already existing JARs (jbossxts-api.jar?) or in a new one (jbossxts-service.jar?). Then, this JAR should be included in the SAR, if it's not already. In this way, the SAR would become just a facility to deploy XTS in JBossAS, but the user could deploy it also on another application server (Tomcat for instance) just by deploying the XTS JARs and providing the necessary configuration wiring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2010