[jboss-svn-commits] JBL Code SVN: r27148 - labs/jbosstm/workspace/adinn/byteman/trunk.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Fri Jun 26 07:01:56 EDT 2009
Author: adinn
Date: 2009-06-26 07:01:56 -0400 (Fri, 26 Jun 2009)
New Revision: 27148
Removed:
labs/jbosstm/workspace/adinn/byteman/trunk/handler.txt
Modified:
labs/jbosstm/workspace/adinn/byteman/trunk/build.xml
Log:
removed dependencies on XTS and targets for testing against XTS as they are neither necessary for nor relevant to byteman
Modified: labs/jbosstm/workspace/adinn/byteman/trunk/build.xml
===================================================================
--- labs/jbosstm/workspace/adinn/byteman/trunk/build.xml 2009-06-26 09:09:35 UTC (rev 27147)
+++ labs/jbosstm/workspace/adinn/byteman/trunk/build.xml 2009-06-26 11:01:56 UTC (rev 27148)
@@ -24,26 +24,8 @@
<!-- the directory in which your installed app server resides -->
<property environment="env"/>
- <!-- pick up the asm.org code transform library -->
- <property name="asm.home" value="${env.HOME}/Download/asm/asm-3.0/output/dist/lib/all"/>
- <property name="asm.jar" value="asm-all-3.0.jar"/>
+ <property name="ext.asm.jars" value="asm-all-3.0.jar"/>
- <condition property="jboss.home" value="${env.JBOSS_HOME}">
- <isset property="env.JBOSS_HOME"/>
- </condition>
-
- <fail unless="jboss.home">
-The JBoss installation directory must be specified with the JBOSS_HOME environment variable or the jboss.home property.
- </fail>
-
- <condition property="xts.home" value="${env.XTS_HOME}">
- <isset property="env.XTS_HOME"/>
- </condition>
-
- <fail unless="xts.home">
-The XTS installation directory must be specified with the XTS_HOME environment variable or the xts.home property.
- </fail>
-
<property name="src.dir" value="src"/>
<property name="dd.dir" value="dd"/>
<property name="dd.grammar.dir" value="${dd.dir}/grammar"/>
@@ -56,25 +38,6 @@
<property name="ext.javacup.jars" value="javacup.jar"/>
<property name="ext.javacup.rt.jars" value="javacuprt.jar"/>
- <!-- we need to add the XTS, TS and various jboss jars to the test code path so we can
- load XTS code -->
-
- <property name="xts.lib.dir" value="${xts.home}/lib"/>
- <property name="xts.sar.dir" value="${xts.home}/sar"/>
- <property name="jboss.lib.dir" value="${jboss.home}/lib"/>
- <property name="jboss.client.dir" value="${jboss.home}/client"/>
- <property name="jboss.common.lib.dir" value="${jboss.home}/common/lib"/>
- <property name="jboss.server.deploy.dir" value="${jboss.home}/server/default/deploy"/>
-
- <property name="xts.lib.jars" value="ws-c10.jar wscf10.jar wscf.jar ws-t10.jar ws-t.jar wstx11.jar wsas.jar ws-c11.jar wscf11.jar ws-c.jar ws-t11.jar wstx10.jar wstx.jar"/>
- <property name="xts.sar.jars" value="jbossxts.sar"/>
- <property name="jboss.lib.jars" value="stax-api.jar"/>
- <property name="jboss.client.jars" value="jbossall-client.jar"/>
- <property name="jboss.common.lib.jars" value="jbossjta.jar jbossws-common.jar jbossws-framework.jar jbossws-spi.jar jbossws-native-saaj.jar jbossws-native-jaxws.jar jbossws-native-jaxws-ext.jar jbossws-native-jaxrpc.jar jboss-javaee.jar"/>
- <property name="jboss.server.deploy.jars" value="jbossws.sar"/>
-
- <!-- enable debugging of XTS service code -->
-
<property name="javac.debug" value="on"/>
<target name="init">
@@ -137,7 +100,7 @@
<target name="compile" depends="init">
<javac srcdir="${src.dir}" destdir="${build.classes.dir}" debug="${javac.debug}">
<classpath>
- <pathelement location="${asm.home}/${asm.jar}"/>
+ <fileset dir="${ext.lib.dir}" includes="${ext.asm.jars}"/>
<fileset dir="${ext.lib.dir}" includes="${ext.javacup.jars}"/>
<fileset dir="${ext.lib.dir}" includes="${ext.javacup.rt.jars}"/>
</classpath>
@@ -170,47 +133,4 @@
<delete dir="${build.dir}"/>
<delete dir="${dd.grammar.dir}" includes="*.java *.tokens"/>
</target>
-
- <target name="TestScript" depends="jar">
- <java classname="org.jboss.byteman.test.TestScript" fork="true">
- <classpath>
- <fileset dir="${build.lib.dir}" includes="byteman.jar"/>
- <pathelement location="${asm.home}/${asm.jar}"/>
- <!-- xts, jta and jboss as jars-->
- <fileset dir="${xts.lib.dir}" includes="${xts.lib.jars}"/>
- <fileset dir="${xts.sar.dir}" includes="${xts.sar.jars}"/>
- <fileset dir="${jboss.lib.dir}" includes="${jboss.lib.jars}"/>
- <fileset dir="${jboss.client.dir}" includes="${jboss.client.jars}"/>
- <fileset dir="${jboss.common.lib.dir}" includes="${jboss.common.lib.jars}"/>
- <fileset dir="${jboss.server.deploy.dir}" includes="${jboss.server.deploy.jars}"/>
- </classpath>
- <!-- uncomment this to see parser debug output
- <jvmarg value="-Dorg.jboss.jbossts.byteman.rule.debug=foo"/>
- -->
- <arg value="handler.txt"/>
- </java>
- </target>
-
- <target name="TestScriptDebug" depends="jar">
- <java classname="org.jboss.byteman.test.TestScript" fork="true">
- <classpath>
- <fileset dir="${build.lib.dir}" includes="byteman.jar"/>
- <pathelement location="${asm.home}/${asm.jar}"/>
- <!-- xts, jta and jboss as jars-->
- <fileset dir="${xts.lib.dir}" includes="${xts.lib.jars}"/>
- <fileset dir="${xts.sar.dir}" includes="${xts.sar.jars}"/>
- <fileset dir="${jboss.lib.dir}" includes="${jboss.lib.jars}"/>
- <fileset dir="${jboss.client.dir}" includes="${jboss.client.jars}"/>
- <fileset dir="${jboss.common.lib.dir}" includes="${jboss.common.lib.jars}"/>
- <fileset dir="${jboss.server.deploy.dir}" includes="${jboss.server.deploy.jars}"/>
- </classpath>
- <jvmarg value="-Xdebug"/>
- <jvmarg value="-Xrunjdwp:transport=dt_socket,server=n,address=5005,suspend=y"/>
- <!-- uncomment this to see parser debug output
- <jvmarg value="-Dorg.jboss.jbossts.byteman.rule.debug=foo"/>
- -->
- <arg value="handler.txt"/>
- </java>
- </target>
-
</project>
Deleted: labs/jbosstm/workspace/adinn/byteman/trunk/handler.txt
===================================================================
--- labs/jbosstm/workspace/adinn/byteman/trunk/handler.txt 2009-06-26 09:09:35 UTC (rev 27147)
+++ labs/jbosstm/workspace/adinn/byteman/trunk/handler.txt 2009-06-26 11:01:56 UTC (rev 27148)
@@ -1,225 +0,0 @@
-##############################################################################
-#
-# Heuristic Recovery After Delayed Commit in Single JVM
-#
-# This script automates testing of a specific recovery scenario for the
-# JBossTS XTS implementation of the WS-AT 1.1 protocol using byteman
-# rules. The scenario is as follows:
-#
-# AS boots
-# Client starts a WS-AT transaction
-# Client invokes web service 1
-# Web service 1 registers as participant P1
-# Client invokes web service 2
-# Web service 2 registers as participant P2
-# Client commits WS-AT transaction
-# Coordinator initiates commit of participant P1
-# ** Rule system intercepts commit and crahses JVM
-#
-# AS reboots
-# Recovery system starts after 2 minutes
-# Recovery system recreates PREPARED WS-AT transaction coordinator
-# Recovery system recreates participant stub for P1
-# ** Rule system adds countdown(2) for P1
-# Recovery system recreates participant stub for P2
-# ** Rule system adds countdown for P2
-# Recovery system calls replay of PREPARED transaction
-# ** Rule system traces PREPARED replay invocation
-# Coordinator sends commit to P1
-# ** Rule system decrements P1's countdown to 1
-#
-# P1 replies with committed
-# ** Rule system intercepts committed message handler and aborts thread
-#
-# Coordinator sends commit to P2
-# ** Rule system decrements P2's countdown to 1
-# (last 2 steps repeated while countdown is active)
-#
-# P2 replies with committed
-# ** Rule system intercepts committed message handler and aborts thread
-# (last 2 steps repeated while countdown is active)
-#
-# Coordinator times out commit and writes heuristic transaction to log
-# Recovery system sleeps
-
-# Recovery system restarts after 2 minutes
-# Recovery system recreates HEURISTIC WS-AT transaction coordinator
-# Recovery system detects existing participant stub for P1
-# Recovery system detects existing participant stub for P2
-#
-# Coordinator sends commit to P1
-# ** Rule system decrements P1's countdown to 0 and removes countdown
-# P1 replies with committed
-# Coordinator sends commit to P2
-# ** Rule system decrements P2's countdown to 0 and removes countdown
-# P2 replies with committed
-# Coordinator clears heuristic log record and copletes commit
-# ** Rule system detects completed commit and kills JVM
-#
-# The number of participants must be at least 2 but can actually be
-# more. One way of exercising the test is to start the AS and run the
-# XTS demo. It should crash at the point of commit. At reboot the
-# rest of the test shoudl run automatically and the server should be
-# killed after a the heuristic transaction is successfuly killed. The
-# console (or server) log should contain messages indicating replays of
-# the prepared and then the heuristic transactions and then a message
-# indicating that the heuristic transacton has committed.
-
-#######################################################################
-# This rule is triggered when a participant stub (CoordinatorEngine) is
-# created from details located in the log record. It adds a countdown
-# which is tripped each time a commit is tried on the participant.
-# While the countdown is active committed messages will be blocked.
-# Note that it calls isRecovered() to detect that the stub has been
-# recreated from the log.
-# The line number is the line immediately following the invocation of
-# the super class constructor. Placing the trigger after the super
-# constructor call is vital for constructors since the rule cannot call
-# methods on the instance until after it has been initialized. In theory
-# it should be possible to set line = -1 and have the rule system compile
-# in the trigger call at the correct place. However, it is not smart enough
-# to do this just yet
-
-RULE add coordinator engine countdown
-CLASS com.arjuna.wst11.messaging.engines.CoordinatorEngine
-METHOD <init>(String, boolean, W3CEndpointReference, boolean, State)
-AFTER WRITE recovered
-BIND engine:CoordinatorEngine = $0,
- recovered:boolean = engine.isRecovered(),
- identifier:String = engine.getId()
-IF recovered
-DO debug("adding countdown for " + identifier),
- addCountDown(identifier, 1)
-ENDRULE
-
-#######################################################################
-# This rule is triggered when a non-recovered participant stub
-# (CoordinatorEngine) is sent a commit message i.e. immediately
-# after a successful prepare. It exits the JVM, simulating a crash.
-# The line number is the first executable line in the method (it
-# could be specified as -1)
-
-RULE kill JVM
-CLASS com.arjuna.wst11.messaging.engines.CoordinatorEngine
-METHOD commit
-AT SYNCHRONIZE
-BIND engine:CoordinatorEngine = $0,
- recovered:boolean = engine.isRecovered(),
- identifier:String = engine.getId()
-IF (NOT recovered)
- AND
- debug("commit on non-recovered engine " + identifier)
-DO debug("!!!killing JVM!!!"),
- killJVM()
-ENDRULE
-
-#######################################################################
-# This rule is triggered when a recovered participant stub
-# (CoordinatorEngine) is sent a commit message i.e. immediately
-# after a successful prepare. It decrements the countdown. First
-# time round this takes it from 1 to 0 but leaves it in place. Second
-# time round it removes it allowing committed messages to flow.
-# The line number is the first executable line in the method (it
-# could be specified as -1)
-
-RULE countdown at commit
-CLASS com.arjuna.wst11.messaging.engines.CoordinatorEngine
-METHOD commit
-AFTER SYNCHRONIZE
-BIND engine:CoordinatorEngine = $0,
- recovered:boolean = engine.isRecovered(),
- identifier:String = engine.getId()
-IF recovered
- AND
- debug("commit on recovered engine " + identifier)
- AND
- debug("counting down")
- AND
- countDown(identifier)
-DO debug("countdown completed for " + identifier)
-ENDRULE
-
-#######################################################################
-# This rule is triggered when a recovered participant stub
-# (CoordinatorEngine) is sent a committed message i.e. in the handler
-# thread which responds to a COMMITTED message from a participant.
-# If it detects a countdown registered using the participant id it
-# throws a runtime exception causing the thread to abort and stopping
-# delivery of the COMMITTED message. The line number is -1 so the
-# rule code gets run as soon as the method is entered.
-
-RULE kill committed thread
-CLASS com.arjuna.wst11.messaging.engines.CoordinatorEngine
-METHOD committed(Notification, AddressingProperties, ArjunaContext)
-AT ENTRY
-BIND engine:CoordinatorEngine = $0,
- recovered:boolean = engine.isRecovered(),
- identifier:String = engine.getId()
-IF recovered
- AND
- debug("committed on recovered engine " + identifier)
- AND
- getCountDown(identifier)
-DO debug("!!!killing committed thread for " + identifier + "!!!"),
- return
-ENDRULE
-
-#######################################################################
-# This rule is triggered when the recovery system finds the PREPARED
-# transaction in the log and reruns the phase 2 commit operation.
-# It prints a message which can be used to verify that the test has
-# worked correctly. The line number is the one where the call to
-# phase2Commit is called but actually the test would also work with
-# line = -1 since the condition selects the correct case.
-
-RULE trace prepared replay
-CLASS org.jboss.jbossts.xts.recovery.coordinator.at.RecoverACCoordinator
-METHOD replayPhase2
-AT INVOKE phase2Commit
-BIND coordinator = $0,
- uid : Uid = coordinator.identifier(),
- status : int = coordinator.status()
-IF (status == com.arjuna.ats.arjuna.coordinator.ActionStatus.PREPARED)
- OR
- (status == com.arjuna.ats.arjuna.coordinator.ActionStatus.COMMITTING)
-DO debug("replaying commit for prepared transaction " + uid)
-ENDRULE
-
-#######################################################################
-# This rule is triggered when the recovery system finds the COMMITTED
-# transaction in the log and reruns the phase 2 commit operation.
-# It prints a message which can be used to verify that the test has
-# worked correctly. The line number is the one where the call to
-# phase2Commit is called but actually the test would also work with
-# line = -1 since the condition selects the correct case.
-
-RULE trace heuristic committed replay
-CLASS org.jboss.jbossts.xts.recovery.coordinator.at.RecoverACCoordinator
-METHOD replayPhase2
-AT INVOKE phase2Commit
-BIND coordinator = $0,
- uid : Uid = coordinator.identifier(),
- status : int = coordinator.status()
-IF status == com.arjuna.ats.arjuna.coordinator.ActionStatus.COMMITTED
-DO debug("replaying commit for heuristic committed transaction " + uid)
-ENDRULE
-
-#######################################################################
-# This rule is triggered when the recovery system deletes the COMMITTED
-# transaction from the log. It prints a message which can be used to
-# verify that the test has worked correctly. It also kills the JVM to
-# halt the test. The line number is the one just following the delete
-# of the record from the TX object store, ensuring that the JVM is not
-# exited until the log has actually been cleaned up.
-
-RULE trace remove committed state
-CLASS com.arjuna.ats.arjuna.coordinator.BasicAction
-METHOD updateState
-AFTER CALL remove_committed
-BIND action : BasicAction = $0,
- uid = action.get_uid()
-IF TRUE
-DO debug("removed committed transaction " + uid),
- debug("!!!killing JVM!!!"),
- killJVM()
-ENDRULE
More information about the jboss-svn-commits
mailing list