merge master branch into 4.0.0-BETA5 release

agent/pom.xml

@@ -34,7 +34,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
 
     <properties>

byteman/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
 
     <description>

contrib/bmunit/pom.xml

@@ -32,7 +32,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
         <relativePath>../../pom.xml</relativePath>
     </parent>
     <build>

contrib/dtest/pom.xml

@@ -33,7 +33,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
         <relativePath>../../pom.xml</relativePath>
     </parent>
     <dependencies>

contrib/jboss-modules-system/plugin/pom.xml

@@ -28,7 +28,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-jboss-modules</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
         <relativePath>../pom.xml</relativePath>
     </parent>
 

contrib/jboss-modules-system/pom.xml

@@ -28,7 +28,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
         <relativePath>../../pom.xml</relativePath>
     </parent>
 

contrib/jboss-modules-system/tests/pom.xml

@@ -19,7 +19,7 @@
 	<parent>
 		<groupId>org.jboss.byteman</groupId>
 		<artifactId>byteman-jboss-modules</artifactId>
-		<version>4.0.0-BETA4</version>
+		<version>4.0.0-BETA5</version>
 		<relativePath>../pom.xml</relativePath>
 	</parent>
 

contrib/rulecheck-maven-plugin/example/pom.xml

@@ -18,7 +18,7 @@
       <plugin>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-rulecheck-maven-plugin</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
         <executions>
           <execution>
             <id>rulecheck-test</id>

contrib/rulecheck-maven-plugin/pom.xml

@@ -32,7 +32,7 @@
 	<parent>
 		<groupId>org.jboss.byteman</groupId>
 		<artifactId>byteman-root</artifactId>
-		<version>4.0.0-BETA4</version>
+		<version>4.0.0-BETA5</version>
 		<relativePath>../../pom.xml</relativePath>
 	</parent>
 

docs/asciidoc/pom.xml

@@ -6,11 +6,10 @@
   <parent>
     <groupId>org.jboss.byteman</groupId>
     <artifactId>byteman-docs</artifactId>
-    <version>4.0.0-BETA4</version>
+    <version>4.0.0-BETA5</version>
   </parent>
 
   <artifactId>byteman-asciidoc</artifactId>
-  <version>4.0.0-BETA4</version>
   <name>Byteman AsciiDoc Documentation</name>
 
   <properties>

docs/asciidoc/src/main/asciidoc/chapters/Byteman-Rule-Language.adoc

@@ -449,21 +449,67 @@ computed each time the rule is triggered before testing the rule condition. For
   ENDRULE
 ----
 
-creates a variable called engine. This variable is bound to the recipient of the commit
+creates a variable called `engine`. This variable is bound to the recipient of the commit
 method call which triggered the rule, identified by the parameter reference `$0` (if commit
 was a static method then reference to `$0` would result in a type check exception).
 Arguments to the trigger method can be identified using parameter references with
 successive indices, `$1`, `$2` etc. The declaration of engine specifies its type as being
 CoordinatorEngine though this is not strictly necessary since it can be inferred form
 the type of `$0`.
 
-Similarly, variables recovered and identifier are bound by evaluating the
-expressions on the right of the = operator. Note that the binding for engine has been
+Similarly, variables `recovered` and `identifier` are bound by evaluating the
+expressions on the right of the `=` operator. Note that the binding for `engine` has been
 established before these variables are bound so it can be referenced in the evaluated
 expression. Once again, type specifications are provided but they could be inferred.
 The special syntax `BIND NOTHING` is available for cases where the rule does not need to
 employ any bindings. Alternatively, the `BIND` clause may be omitted.
 
+==== Downcasts At Rule Variable Initialization
+
+A binding initialization can do more than simply introduce a place holder for the value
+computed in the initializer expression and in this respect it differs significantly
+from an assignment that occurs elsewhere in the rule body. It is possible to perform a
+'downcast' in a binding initialization i.e. assigning a value of some generic class type
+to a rule variable whose type is a compatible subclass type.
+
+For example, in the following rule
+
+----
+  # downcast example
+  RULE countdown at commit
+  CLASS com.arjuna.wst11.messaging.engines.CoordinatorEngine
+  METHOD commit
+  AT READ state
+  BIND engine:CoordinatorEngine = $0;
+       endpoint : javax.xml.ws.EndpointReference = engine.participant;
+       w3cEndpoint javax.xml.ws.wsaddressing.W3CEndpointReference = endpoint;
+  . . .
+  ENDRULE
+----
+
+the reference stored in the `CoordinatorEngine` field `participant` is used to initialize rule
+variable `endpoint` whose type is the generic JaxWS class `EndpointReference`. The second
+binding for rule variable `w3cEndpoint` uses the value stored in `endpoint`. The type of this
+second variable `w3cEdpoint` is subclass `W3CEndpointReference` of the type `EndpointReference` of
+the initializing expression. In an assignment anywhere else in a rule this would lead to a type error.
+The Byteman type checker ignores the type mismatch in this initializing assignment, but only because
+it knows that `W3CEndpointReference` is a subclass of the type for the intiializer expression,
+`endpoint`. It assumes that the 'downcast' at this point is deliberate, i.e. that the
+rule author knows that the value returned by the initializer expression will in fact belongs to the
+subtype.
+
+Byteman still performs a type check when it executes the initialization to ensure that the
+value is indeed of the required type, throwing an exception if the test fails. n.b. in this case the
+assignment will never fail because `CoordinatorEngine` field `participant` is actually declared as
+a `W3CEndpointReference`.
+
+Downcasting is particularly useful when rules need to handle generic types like `List` etc. The
+Byteman type checker cannot identify information about generic types from bytecode because it is
+erased at compile time. So, for example, a list `get` operation will always be typed as returning
+an Object. If you know that a specific list available at the injection point stores values of some
+given type then a value retrieved from the list can be downcast to the desired type in the BIND
+clause.
+
 === Rule Expressions
 
 Expressions which occur on the right hand side of the = operator in event bindings can be

docs/pom.xml

@@ -6,11 +6,10 @@
   <parent>
     <groupId>org.jboss.byteman</groupId>
     <artifactId>byteman-root</artifactId>
-    <version>4.0.0-BETA4</version>
+    <version>4.0.0-BETA5</version>
   </parent>
 
   <artifactId>byteman-docs</artifactId>
-  <version>4.0.0-BETA4</version>
   <name>Byteman Documentation</name>
   <packaging>pom</packaging>
 

download/pom.xml

@@ -28,7 +28,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
     <description>
         The Byteman download includes the byteman agent, submit and install jars. the contributed

install/pom.xml

@@ -33,7 +33,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
 
     <profiles>

jigsaw/pom.xml

@@ -41,7 +41,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
     <properties>
         <!-- don't install or deploy this jar, instead use it to

layer/pom.xml

@@ -36,7 +36,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
     <build>
         <plugins>

pom.xml

@@ -33,7 +33,7 @@
         into Java application and JVM runtime methods. Its primary purpose is to support execution tracing and fault
         injection testing.
     </description>
-    <version>4.0.0-BETA4</version>
+    <version>4.0.0-BETA5</version>
     <name>byteman-root</name>
     <url>http://www.jboss.org/byteman</url>
 

sample/pom.xml

@@ -28,7 +28,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
     <description>
         The Byteman sample jar contains some example helper classes and auxiliary classes used by the]

submit/pom.xml

@@ -33,7 +33,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
     <build>
       <plugins>

tests/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <groupId>org.jboss.byteman</groupId>
         <artifactId>byteman-root</artifactId>
-        <version>4.0.0-BETA4</version>
+        <version>4.0.0-BETA5</version>
     </parent>
 
     <description>