[JBoss JIRA] (JBTM-1495) Merge in BlackTie
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1495?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1495:
--------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M3)
> Merge in BlackTie
> -----------------
>
> Key: JBTM-1495
> URL: https://issues.jboss.org/browse/JBTM-1495
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 weeks
> Remaining Estimate: 2 weeks
>
> Docs, code, forums, chat room (motd), Jira, web pages
> Need to add *.c, *.bat, *.sh, makefile to NarayanaReleaseProcess script when search and replacing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1551) Empty '.m2/repository/org/jboss/narayana' prior to running CI
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1551?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1551:
--------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M3)
> Empty '.m2/repository/org/jboss/narayana' prior to running CI
> -------------------------------------------------------------
>
> Key: JBTM-1551
> URL: https://issues.jboss.org/browse/JBTM-1551
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.Final
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> This ensures that no old artefacts are picked up.
> Need to wait for BT to be merged into Narayana as it relies on Narayana artefacts being present in .m2. A failed Narayana build will result in these artefacts being missing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1147 started by Ondřej Chaloupka.
> 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: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M3
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> 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}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1365) Deploy REST-AT support as a JBossAS subsystem and module
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1365?focusedWorklogId=12429199&page=... ]
Gytis Trikleris logged work on JBTM-1365:
-----------------------------------------
Author: Gytis Trikleris
Created on: 21/May/13 5:28 AM
Start Date: 21/May/13 5:28 AM
Worklog Time Spent: 1 minute
Issue Time Tracking
-------------------
Remaining Estimate: 3 days (was: 2 days, 4 hours, 50 minutes)
Time Spent: 2 weeks, 2 days, 3 hours, 11 minutes (was: 2 weeks, 2 days, 3 hours, 10 minutes)
Worklog Id: (was: 12429199)
> Deploy REST-AT support as a JBossAS subsystem and module
> --------------------------------------------------------
>
> Key: JBTM-1365
> URL: https://issues.jboss.org/browse/JBTM-1365
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: REST
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Original Estimate: 3 weeks
> Time Spent: 2 weeks, 2 days, 3 hours, 11 minutes
> Remaining Estimate: 3 days
>
> Currently a user of REST-AT needs to deploy the coordinator and also create a new module for the REST-AT client support. It would be a lot easier for developers if this was already deployed as part of AS7.
> I think the way to do this is to create a sub-system for the coordinator (like what we do for the XTS coordinator) and a module for the REST-AT libraries (again, similar to XTS).
> The subsystem would need to:
> * Bootstrap the coordinator. Currently bootstrapping occurs when the coordinator war is deployed. As there will be no war, the subsystem needs to take care of this bootstrapping.
> * Deploy the coordinator endpoint.
> The module would need to contain the REST-AT coordinator code and the client libraries.
> h3. Open Issues
> Need to check with the AS team to see if we add a new Subsystem or make do with an existing one. We can't start this work until this is resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1365) Deploy REST-AT support as a JBossAS subsystem and module
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1365?focusedWorklogId=12429198&page=... ]
Gytis Trikleris logged work on JBTM-1365:
-----------------------------------------
Author: Gytis Trikleris
Created on: 21/May/13 5:28 AM
Start Date: 21/May/13 5:27 AM
Worklog Time Spent: 3 days
Issue Time Tracking
-------------------
Remaining Estimate: 2 days, 4 hours, 50 minutes (was: 1 week, 4 hours, 50 minutes)
Time Spent: 2 weeks, 2 days, 3 hours, 10 minutes (was: 1 week, 4 days, 3 hours, 10 minutes)
Worklog Id: (was: 12429198)
> Deploy REST-AT support as a JBossAS subsystem and module
> --------------------------------------------------------
>
> Key: JBTM-1365
> URL: https://issues.jboss.org/browse/JBTM-1365
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: REST
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Original Estimate: 3 weeks
> Time Spent: 2 weeks, 2 days, 3 hours, 10 minutes
> Remaining Estimate: 2 days, 4 hours, 50 minutes
>
> Currently a user of REST-AT needs to deploy the coordinator and also create a new module for the REST-AT client support. It would be a lot easier for developers if this was already deployed as part of AS7.
> I think the way to do this is to create a sub-system for the coordinator (like what we do for the XTS coordinator) and a module for the REST-AT libraries (again, similar to XTS).
> The subsystem would need to:
> * Bootstrap the coordinator. Currently bootstrapping occurs when the coordinator war is deployed. As there will be no war, the subsystem needs to take care of this bootstrapping.
> * Deploy the coordinator endpoint.
> The module would need to contain the REST-AT coordinator code and the client libraries.
> h3. Open Issues
> Need to check with the AS team to see if we add a new Subsystem or make do with an existing one. We can't start this work until this is resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months