May 2012 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-953) Remove home-brew SOAP stack from XTS unit tests

by Paul Robinson (Created) (JIRA)

Remove home-brew SOAP stack from XTS unit tests ----------------------------------------------- Key: JBTM-953 URL: https://issues.jboss.org/browse/JBTM-953 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Priority: Minor Fix For: 5.0.0.Final In the past these tests used a mock/simple SOAP stack developed specifically for the tests. This stack is no longer used as the tests run within JBoss AS. This code is redundant and should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

4
7
0 / 0

[JBoss JIRA] (JBTM-1007) Review annotation names offered by the TXFramework

by Paul Robinson (Created) (JIRA)

Review annotation names offered by the TXFramework -------------------------------------------------- Key: JBTM-1007 URL: https://issues.jboss.org/browse/JBTM-1007 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: TXFramework Affects Versions: 5.0.0.M1 Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.Final Essentially, we need to ensure that they provide a good description to the user of what they do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
3
0 / 0

[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1147: ----------------------------------- Summary: Refactor ParticipantCompletion recovery tests to remove duplicate rules Key: JBTM-1147 URL: https://issues.jboss.org/browse/JBTM-1147 Project: JBoss Transaction Manager Issue Type: Enhancement Security Level: Public (Everyone can see) Components: XTS Affects Versions: 5.0.0.M1, 4.16.4 Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 4.16.5, 5.0.0.Final The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example: The following rules in BACrashDuringCommit could be refactored into a single rule {code} ##################################################################### # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest # RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest METHOD run() AT ENTRY IF TRUE DO debug("creating counter and rendezvous"), createCounter("closes", 3), createRendezvous("closes-complete", 2) ENDRULE ##################################################################### # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest # RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest METHOD run() AT ENTRY IF TRUE DO debug("creating counter and rendezvous"), createCounter("closes", 3), createRendezvous("closes-complete", 2) ENDRULE ##################################################################### # Setup counter MultiServiceParticipantCompletionParticipantCloseTest # RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest METHOD run() AT ENTRY IF TRUE DO debug("creating counter and rendezvous"), createCounter("closes", 3), createRendezvous("closes-complete", 2) ENDRULE ##################################################################### # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest # RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest METHOD run() AT ENTRY IF TRUE DO debug("creating counter and rendezvous"), createCounter("closes", 3), createRendezvous("closes-complete", 2) ENDRULE {code} These can be re-factored in to a rule like this: {code} RULE setup counter INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest METHOD run() AT ENTRY IF $0.getClass().getName().contains("ParticipantCompletionParticipant") DO debug("creating counter and rendezvous"), createCounter("closes", 3), createRendezvous("closes-complete", 2) ENDRULE {code} Also, the following similar rules are also present in this file: {code} ##################################################################### # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest # RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest METHOD run() AT CALL UserBusinessActivity.close() IF TRUE DO debug("waiting to call close"), rendezvous("closes-complete"), debug("rendezvous complete, calling close") ENDRULE ##################################################################### # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest # RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest METHOD run() AT CALL UserBusinessActivity.close() IF TRUE DO debug("waiting to call close"), rendezvous("closes-complete"), debug("rendezvous complete, calling close") ENDRULE ##################################################################### # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest # RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest METHOD run() AT CALL UserBusinessActivity.close() IF TRUE DO debug("waiting to call close"), rendezvous("closes-complete"), debug("rendezvous complete, calling close") ENDRULE ##################################################################### # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest # RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest METHOD run() AT CALL UserBusinessActivity.close() IF TRUE DO debug("waiting to call close"), rendezvous("closes-complete"), debug("rendezvous complete, calling close") ENDRULE {code} Which could be replaced with something like this: {code} RULE wait for closes INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest METHOD run() AT CALL UserBusinessActivity.close() IF $0.getClass().getName().contains("ParticipantCompletionParticipant") DO debug("waiting to call close"), rendezvous("closes-complete"), debug("rendezvous complete, calling close") ENDRULE {code} We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
4
0 / 0

[JBoss JIRA] (JBTM-1155) Remember where we are in the commit list for recovery

by Mark Little (JIRA)

Mark Little created JBTM-1155: --------------------------------- Summary: Remember where we are in the commit list for recovery Key: JBTM-1155 URL: https://issues.jboss.org/browse/JBTM-1155 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Recovery, Transaction Core Affects Versions: 4.16.4 Reporter: Mark Little Assignee: Tom Jenkinson Fix For: 5.0.0.Final We keep track of where the coordinator is in the list of resources to commit during doCommit, so that we can avoid heuristics as much as possible. Basically we need to remember if we have gotten past the first participant. However, we do not remember this value (boolean) as part of the transaction state. This means that upon recovery there is a chance that a participant that failed to commit the first time round and then causes a heuristic rollback subsequently, will cause the transaction silently mask the heuristic and roll back all of the other participants, delete the log and report a normal transaction abort state. In fact it should ensure the heuristic is raised. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-223) Check WL-to-JBossTS interoperability (via JTS).

by Mark Little (JIRA)

Check WL-to-JBossTS interoperability (via JTS). ----------------------------------------------- Key: JBTM-223 URL: http://jira.jboss.com/jira/browse/JBTM-223 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Reporter: Mark Little Assigned To: Mark Little -- 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

11 years, 11 months

2
4
0 / 0

[JBoss JIRA] (JBTM-1166) Remove dependency on AS6 component matrix in the REST module

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-1166: -------------------------------------- Summary: Remove dependency on AS6 component matrix in the REST module Key: JBTM-1166 URL: https://issues.jboss.org/browse/JBTM-1166 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: REST Reporter: Michael Musgrove Assignee: Michael Musgrove The REST module still contains a dependency on the AS6 component matrix. Update the pom to use jboss-javaee-6.0 for dependency management. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
1
0 / 0

[JBoss JIRA] (JBTM-981) Annotation support for transaction bridging

by Paul Robinson (Created) (JIRA)

Annotation support for transaction bridging ------------------------------------------- Key: JBTM-981 URL: https://issues.jboss.org/browse/JBTM-981 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M2 Currently the developer specifies the type of transaction that the service and any lifecycle callbacks expect to participate in. For example, via @WSBA or @RESTJDI class level annotation. However, the participation requirements for these protocols is very similar. It would be better if the developer could simply specify that the service can participate in any forward compensation style transaction (such as REST-JDI or WS-BA) using a @BA annotation. The type of transaction is determined by the inflowed TX context. To take this a step further, by leaving off the transaction type annotation altogether, the service could participate in any transaction type. Of course, this would require a mix of ACID and forward compensation lifecycle callbacks to be present. Again, the inflow TX context would decide the actual TX type used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
10
0 / 0

[JBoss JIRA] (JBTM-1091) TXFramework Quickstart: Protocol Switching, JTS -> WS-AT -> REST-AT

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1091: ----------------------------------- Summary: TXFramework Quickstart: Protocol Switching, JTS -> WS-AT -> REST-AT Key: JBTM-1091 URL: https://issues.jboss.org/browse/JBTM-1091 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: TXFramework Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
3
0 / 0

[JBoss JIRA] (JBTM-1102) Research exisiting WS-AT and WS-BA APIs and Bridging

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1102: ----------------------------------- Summary: Research exisiting WS-AT and WS-BA APIs and Bridging Key: JBTM-1102 URL: https://issues.jboss.org/browse/JBTM-1102 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: TXFramework Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
5
0 / 0

[JBoss JIRA] (JBTM-1175) Add warning message during recovery if heuristic occurs

by Mark Little (JIRA)

Mark Little created JBTM-1175: --------------------------------- Summary: Add warning message during recovery if heuristic occurs Key: JBTM-1175 URL: https://issues.jboss.org/browse/JBTM-1175 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA, JTS, Recovery, Transaction Core Affects Versions: 4.16.4 Reporter: Mark Little Assignee: Mark Little Heuristics during recovery used to be treated via the OTS hooking in various notification mechanisms, e.g., the CORBA notification service. That code is gone and as a result we silently ignore heuristics during recovery. This is not an issue for consistency, because the heuristic resolution tool(s) were always intended to scan the object store and flag all logs that are in a heuristic state. However, it might be nice for admins to have a pro-active indication that a failure has occurred. Need to check all recovery instances for those that are now silent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2012