[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1147:
--------------------------------
Assignee: Ondřej Chaloupka (was: Amos Feng)
> 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: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M2
>
> 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, 10 months
[JBoss JIRA] (JBTM-1355) Merge XTS JUnit and Arquillian tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1355?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1355:
--------------------------------
Labels: (was: assign)
> Merge XTS JUnit and Arquillian tests
> ------------------------------------
>
> Key: JBTM-1355
> URL: https://issues.jboss.org/browse/JBTM-1355
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 4 hours
> Time Spent: 7 hours
> Remaining Estimate: 0 minutes
>
> When migrating the XTS tests to Arquillian, we wanted to make sure that the old tests where still functional whilst the Arquillian counterparts stabilized. As a result we now have two classes for each test. The Arquillian test delegates each @Test method to the corresponding @Test in the old suite.
> For example:
> We have the actual test in:
> ./XTS/localjunit/WSTX/src/main/java/com/arjuna/wst11/tests/arq/ba/MultiClose.java
> And then a Arquillian JUnit test which just calls the test methods above is here:
> ./XTS/localjunit/WSTX/src/test/java/com/arjuna/wst11/tests/arq/ba/MultiCloseTest.java
> To resolve this issue, we should remove the tests under './XTS/localjunit/WSTX/src/main/java' and merge the test methods into Arquillian test. At the end of this process "./XTS/localjunit/WSTX/src/main" should be empty (and thus removed).
> This applies to most, if not all suites under "./XTS/localjunit/".
--
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, 10 months
[JBoss JIRA] (JBTM-1016) Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1016?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1016:
--------------------------------
Fix Version/s: 5.0.0.M2
(was: 5.0.0.Final)
> Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1016
> URL: https://issues.jboss.org/browse/JBTM-1016
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Labels: assign
> Fix For: 5.0.0.M2
>
>
> I've found many bugs in the XTS crash recovery tests that where due to changes being made to the XTS code without updating the byteman scripts. The problem is that these inconsistencies often go unnoticed when the tests run, until you notice a failure in the test.
> Can we run bmcheck as part of the maven build and make the build fail if it detects errors? Needs to be integrated into the poms, perhaps by an exec in an antrun plugin
> NOTE: Before raising the pull req it will be necessary to resolve any the discovered errors.
--
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, 10 months
[JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-986:
------------------------------------
I've added a prototype WSTXFeature in this commit: https://github.com/paulrobinson/narayana/commit/575f61d1bc1623935fb4d87ee...
To use this you need to build JBossWS from source. Here's the steps:
1. Add the Apache snapshot repo to your ~/.m2/settings.xml:
{code}
<repository>
<id>apache-snapshots</id>
<name>Apache SNAPSHOT Repository</name>
<url>http://repository.apache.org/snapshots/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
{code}
Build JBossWS CXF (change for your env)
{code}
svn co http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/ jbossws-cxf
cd jbossws-cxf
ant -Djboss720.home=/Users/paul/dev/jboss-as.ts/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT deploy-jboss720 -DskipTests=true
{code}
Build JBossWS API
{code}
svn co http://anonsvn.jboss.org/repos/jbossws/api/trunk jbossws-api
cd jbossws-api
mvn clean install -DskipTests
{code}
Update versions in JBossAS root pom.xml, based on this diff:
{code}
- <version.org.jboss.ws.api>1.0.1.Final</version.org.jboss.ws.api>
+ <version.org.jboss.ws.api>1.0.2-SNAPSHOT</version.org.jboss.ws.api>
- <version.org.jboss.ws.cxf>4.1.1.Final</version.org.jboss.ws.cxf>
+ <version.org.jboss.ws.cxf>4.2.0-SNAPSHOT</version.org.jboss.ws.cxf>
{code}
Build JBossAS and Narayana as normal.
You can run this TXFramework test to see this in action:
{code}
cd txframework
mvn test -Parq-remote -Dtest=org.jboss.narayana.txframework.functional.ws.at.simplePOJO.ATTest
{code}
> Automatically setup the client side handler chain
> -------------------------------------------------
>
> Key: JBTM-986
> URL: https://issues.jboss.org/browse/JBTM-986
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 days
> Time Spent: 2 days, 6 hours
> Remaining Estimate: 1 day, 2 hours
>
> When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the client stub to manage transaction context propagation. The code required to do this is as follows:
> {code}
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
> {code}
> This is not very user friendly.
> This could be done using a JAX-WS feature passed to the Client-side port.
> We also need to support client stubs created using @WebServiceRef. Here's some examples of its use:
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> The feature should be "enabled" by default providing the feature is enabled in the XTS server config.
> The quickstarts also need updated to use this.
--
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, 10 months
[JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-986:
------------------------------------
Info from Alessio. I don't think he will mind me quoting him here:
{quote}
Hi Paul,
I've been having a look at your scenario and think I have something that
could address your needs. I've just added the following class to the
jbossws-api: [1]. You could basically extend it, override the
initializeBindingProvider method to set jaxws handlers in the passed
BindingProvider instance (it will be your port) and do whatever you need
to do for XTS in the handler you added.
The feature above is now detected in the jbossws flavour of the jaxws
ServiceDelegate CXF impl, see class JBossWSServiceImpl in [2].
The jira for this new feature is https://issues.jboss.org/browse/JBWS-3591 .
I believe this should be ok, let me know what you think, or let's simply
chat on IRC.
Cheers
Alessio
[1]
http://anonsvn.jboss.org/repos/jbossws/api/trunk/src/main/java/org/jboss/...
[2]
http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/client/src...
{quote}
> Automatically setup the client side handler chain
> -------------------------------------------------
>
> Key: JBTM-986
> URL: https://issues.jboss.org/browse/JBTM-986
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 days
> Time Spent: 2 days, 6 hours
> Remaining Estimate: 1 day, 2 hours
>
> When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the client stub to manage transaction context propagation. The code required to do this is as follows:
> {code}
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
> {code}
> This is not very user friendly.
> This could be done using a JAX-WS feature passed to the Client-side port.
> We also need to support client stubs created using @WebServiceRef. Here's some examples of its use:
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> The feature should be "enabled" by default providing the feature is enabled in the XTS server config.
> The quickstarts also need updated to use this.
--
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, 10 months