| Chapter | Assertions | Testable | Total Tested | Total Tests | Tested (problematic) |
Tested (working) |
Coverage % |
|---|---|---|---|---|---|---|---|
| 1 Overview | 15 | 12 | 3 | 0 | 0 | 3 | 25.00% |
| 2 Interceptor Life Cycle | 9 | 9 | 0 | 0 | 0 | 0 | 0.00% |
| 3 Method interceptors | 23 | 19 | 14 | 8 | 0 | 14 | 73.68% |
| 4 Timeout Method Interceptors | 25 | 0 | 0 | 0 | 0 | 0 | |
| 5 Interceptors for LifeCycle Event Callbacks | 31 | 25 | 13 | 7 | 0 | 13 | 52.00% |
| 6 InvocationContext | 18 | 17 | 12 | 0 | 0 | 12 | 70.59% |
| 7 Default Interceptors | 4 | 0 | 0 | 0 | 0 | 0 | |
| 8 Method-level Interceptors | 11 | 7 | 7 | 0 | 0 | 7 | 100.00% |
| 9 Specification of Interceptors in the Deployment Descriptor | 15 | 0 | 0 | 0 | 0 | 0 | |
| Total | 151 | 89 | 49 | 15 | 0 | 49 | 55.06% |
| Section | Assertions | Testable | Total Tested | Tested (problematic) | Tested (working) | Coverage % |
|---|---|---|---|---|---|---|
| 1 Overview | 15 | 12 | 3 | 0 | 3 | 25.00% |
| 2 Interceptor Life Cycle | 9 | 9 | 0 | 0 | 0 | 0.00% |
| 3 Method interceptors | 9 | 9 | 6 | 0 | 6 | 66.67% |
| 3.1 Multiple Method Interceptor Methods | 9 | 6 | 5 | 0 | 5 | 83.33% |
| 3.2 Exceptions | 5 | 4 | 3 | 0 | 3 | 75.00% |
| 4 Timeout Method Interceptors | 11 | 0 | 0 | 0 | 0 | |
| 4.1 Multiple Timeout Method Interceptor Methods | 9 | 0 | 0 | 0 | 0 | |
| 4.2 Exceptions | 5 | 0 | 0 | 0 | 0 | |
| 5 Interceptors for LifeCycle Event Callbacks | 14 | 10 | 6 | 0 | 6 | 60.00% |
| 5.1 Multiple Callback Interceptor Methods for a Life Cycle Callback Event | 11 | 10 | 4 | 0 | 4 | 40.00% |
| 5.2 Exceptions | 6 | 5 | 3 | 0 | 3 | 60.00% |
| 6 InvocationContext | 18 | 17 | 12 | 0 | 12 | 70.59% |
| 7 Default Interceptors | 4 | 0 | 0 | 0 | 0 | |
| 8 Method-level Interceptors | 11 | 7 | 7 | 0 | 7 | 100.00% |
| 9 Specification of Interceptors in the Deployment Descriptor | 1 | 0 | 0 | 0 | 0 | |
| 9.1 Specification of Interceptors | 3 | 0 | 0 | 0 | 0 | |
| 9.2 Binding of Interceptors to TargetClasses | 11 | 0 | 0 | 0 | 0 |
| Colour Key |
|---|
| Assertion is covered |
| Assertion is not covered |
| Assertion test is unimplemented |
| Assertion is untestable |
An interceptor class is a class (distinct from the target class) whose methods are invoked in response to invocations and/or lifecycle events on the target class.
Coverage
No tests exist for this assertion
Any number of interceptor classes may be associated with a target class.
Coverage
No tests exist for this assertion
It is possible to carry state across multiple interceptor method invocations for a single method invocation or lifecycle callback event in the context data of the InvocationContext object.
An interceptor class must have a public no-arg constructor.
Coverage
No tests exist for this assertion
Interceptor methods and interceptor classes are defined for a class by means of metadata annotations or the deployment descriptor.
Coverage
No tests exist for this assertion
When annotations are used, one or more interceptor classes are denoted using the Interceptors annotation on the target class itself and/or on its methods.
Coverage
No tests exist for this assertion
In the method case, the Interceptors annotation can be applied to a method of the class or superclass.
Coverage
No tests exist for this assertion
The deployment descriptor may be used as an alternative to specify the invocation order of interceptors or to override the order specified in metadata annotations.
Test that the deployment descriptor can be used to specify the invocation order.
Test that the deployment descriptor overrides the order specified by the annotations.
An interceptor implementation is not required to support the deployment descriptor approach to specifying interceptor metadata.
Coverage
No tests exist for this assertion
The @Interceptor annotation may be used to explicitly designate a class as an interceptor class. Support for this annotation is not required.
Coverage
No tests exist for this assertion
The @InterceptorBinding annotation specifies that an annotation type is an interceptor binding type. Support for this annotation is not required.
Coverage
No tests exist for this assertion
Default interceptors may be defined using the deployment descriptor.
The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated.
Coverage
No tests exist for this assertion
When the target instance is created, a corresponding interceptor instance is created for each associated interceptor class.
Coverage
No tests exist for this assertion
These interceptor instances are destroyed when the target instance is removed.
Coverage
No tests exist for this assertion
Both the interceptor instance and the target instance are created before any PostConstruct callbacks are invoked. Any PreDestroy callbacks are invoked before the destruction of either the target instance or interceptor instance.
Coverage
No tests exist for this assertion
An interceptor instance may hold state.
Coverage
No tests exist for this assertion
An interceptor instance may be the target of dependency injection. Dependency injection is performed when the interceptor instance is created, using the naming context of the associated target class.
Coverage
No tests exist for this assertion
The PostConstruct interceptor callback method is invoked after this dependency injection has taken place on both the interceptor instances and the target instance.
Coverage
No tests exist for this assertion
An interceptor class shares the enterprise naming context of its associated target class.
Coverage
No tests exist for this assertion
Annotations and/or XML deployment descriptor elements for dependency injection or for direct JNDI lookup refer to this shared naming context.
Coverage
No tests exist for this assertion
Around-invoke methods can have public, private, protected, or package level access. An around-invoke method must not be declared as final or static.
Around-invoke methods have the following signature: Object <METHOD>(InvocationContext) throws Exception
Coverage
No tests exist for this assertion
An around-invoke method can invoke any component or resource that the method it is intercepting can invoke.
Coverage
No tests exist for this assertion
Around-invoke method invocations occur within the same transaction and security context as the method on which they are interposing.
Coverage
No tests exist for this assertion
The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
Default interceptors, if any, are invoked first. Default interceptors can only be specified in the deployment descriptor. Default interceptors are invoked in the order of their specification in the deployment descriptor.
If there are any interceptor classes associated with the target class using the Interceptors annotation, the interceptor methods defined by those interceptor classes are invoked before any interceptor methods defined on the target class itself.
If an interceptor class itself has superclasses, the interceptor methods defined by the interceptor class's superclasses are invoked before the interceptor method defined by the interceptor class, most general superclass first.
After the interceptor methods defined on interceptor classes have been invoked, then, in order: If any method-level interceptors are defined for the target class method that is to be invoked, the methods defined on those interceptor classes are invoked in the same order as the specification of those interceptor classes in the Interceptors annotation applied to that target class method. If a target class has superclasses, any around-invoke methods defined on those superclasses are invoked, most general superclass first. The around-invoke method, if any, on the target class itself is invoked.
The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
The InvocationContext object provides metadata that enables interceptor methods to control the behaviour of the invocation chain, including whether the next method in the chain is invoked and the values of its parameters and result.
Coverage
No tests exist for this assertion
Around-invoke methods are allowed to catch and suppress exceptions and recover by calling proceed(). Around-invoke methods are allowed to throw runtime exceptions or any checked exceptions that the associated target method allows within its throws clause.
Around-invoke methods run in the same Java call stack as the associated target method.
Coverage
No tests exist for this assertion
InvocationContext.proceed() will throw the same exception as any thrown by the associated target method unless an interceptor further down the Java call stack has caught it and thrown a different exception.
Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed() method.
Interceptor methods that interpose on timeout methods are denoted by the AroundTimeout annotation or around-timeout deployment descriptor element.
Around-timeout methods may be defined on interceptor classes and the target class (or superclass). However, only one AroundTimeout method may be present on a given class.
Around-timer methods can have public, private, protected, or package level access.
Test with a public method.
Test with a private method.
Test with a protected method.
Test with a package method.
An around-timer method must not be declared as final or static.
Around-timer methods must have the following signature: Object <METHOD>(InvocationContext) throws Exception
An around-timer method can invoke any component or resource that its corresponding timeout method can invoke.
Around-timer method invocations occur within the same transaction and security context as the timeout method on which they are interposing.
The InvocationContext.getTimer() method allows the around-timeout method to retrieve the timer object associated with the timeout.
If multiple timeout method interceptor methods are defined for a target class, the following rules governing their invocation order apply. The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
Default interceptors, if any, are invoked first. Default interceptors can only be specified in the deployment descriptor. Default interceptors are invoked in the order of their specification in the deployment descriptor.
If there are any interceptor classes associated with the target class using the Interceptors annotation, the interceptor methods defined by those interceptor classes are invoked before any interceptor methods defined on the target class itself.
The around-timeout methods defined on those interceptor classes are invoked in the same order as the specification of the interceptor classes in the Interceptors annotation.
If an interceptor class itself has superclasses, the interceptor methods defined by the interceptor class's superclasses are invoked before the interceptor method defined by the interceptor class, most general superclass first.
After the interceptor methods defined on interceptor classes have been invoked, then, in order: If any method-level interceptors are defined for the target class method that is to be invoked, the methods defined on those interceptor classes are invoked in the same order as the specification of those interceptor classes in the Interceptors annotation applied to that target class method. If a target class has superclasses, any around-timeout methods defined on those superclasses are invoked, most general superclass first. The around-timeout method, if any, on the target class itself is invoked.
If an around-timeout method is overridden by another method (regardless of whether that method is itself an around-timeout method), it will not be invoked.
The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
The InvocationContext object provides metadata that enables interceptor methods to control the behaviour of the invocation chain, including whether the next method in the chain is invoked and the values of its parameters and result.
Around-timeout interceptor methods may throw any exceptions that are allowed in the throws clause of the timeout method on which they are interposing.
Around-timeout methods are allowed to catch and suppress exceptions and recover by calling proceed(). Around-timeout methods are allowed to throw runtime exceptions or any checked exceptions that the associated target method allows within its throws clause.
Around-timeout methods run in the same Java call stack as the associated target method.
InvocationContext.proceed() will throw the same exception as any thrown by the associated target method unless an interceptor further down the Java call stack has caught it and thrown a different exception.
Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed() method.
Interceptor methods for a lifecycle event callbacks can be defined on an interceptor class and/or directly on the target class. The PostConstruct and PreDestroy annotations are used to define an interceptor method for a lifecycle callback event.
If the deployment descriptor is used to define interceptors, the post-construct and pre-destroy elements are used.
Lifecycle callback interceptor methods and AroundInvoke interceptor methods may be defined on the same interceptor class.
Lifecycle callback interceptor methods are invoked in an unspecified security context.
Lifecycle callback interceptor methods are invoked in an unspecified transaction context.
Lifecycle callback interceptor methods may be defined on superclasses of the target class or interceptor classes. However, a given class may not have more than one lifecycle callback interceptor method for the same lifecycle event. Any subset or combination of lifecycle callback annotations may be specified on a given class.
Coverage
No tests exist for this assertion
A single lifecycle callback interceptor method may be used to interpose on multiple callback events.
Coverage
No tests exist for this assertion
Lifecycle callback interceptor methods defined on an interceptor class have the following signature: void <METHOD>(InvocationContext)
Coverage
No tests exist for this assertion
Lifecycle callback interceptor methods defined on a target class have the following signature: void <METHOD>()
Coverage
No tests exist for this assertion
Lifecycle callback interceptor methods can have public, private, protected or package level access.
A lifecycle callback interceptor method must not be declared as final or static.
If multiple callback interceptor methods are defined for a lifecycle event for a target class, the following rules governing their invocation order apply. The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
Coverage
No tests exist for this assertion
Default interceptors, if any, are invoked first. Default interceptors can only be specified in the deployment descriptor. Default interceptors are invoked in the order of their specification in the deployment descriptor.
Coverage
No tests exist for this assertion
If there are any interceptor classes associated with the target class using the Interceptors annotation, the lifecycle callback interceptor methods defined by those interceptor classes are invoked before any lifecycle callback interceptor methods defined on the target class itself.
The lifecycle callback interceptor methods defined on those interceptor classes are invoked in the same order as the specification of the interceptor classes in the Interceptors annotation.
If an interceptor class itself has superclasses, the lifecycle callback interceptor methods defined by the interceptor class's superclasses are invoked before the lifecycle callback interceptor method defined by the interceptor class, most general superclass first.
After the lifecycle callback interceptor methods defined on interceptor classes have been invoked, then if a target class has superclasses, any lifecycle callback interceptor methods defined on those superclasses are invoked, most general superclass first. The lifecycle callback interceptor method, if any, on the target class itself is invoked.
If a lifecycle callback interceptor method is overridden by another method (regardless of whether that method is itself a lifecycle callback interceptor method (of the same or different type)), it will not be invoked.
Coverage
No tests exist for this assertion
The deployment descriptor may be used to override the interceptor invocation order specified in annotations.
All lifecycle callback interceptor methods for a given lifecycle event run in the same Java call stack.
Coverage
No tests exist for this assertion
If there is no corresponding callback method on the target class (or any of its superclasses), the InvocationContext.proceed() invocation on the last interceptor method defined on an interceptor class in the chain will be a no-op.
Coverage
No tests exist for this assertion
The InvocationContext object provides metadata that enables interceptor methods to control the invocation of further methods in the chain.
Coverage
No tests exist for this assertion
The lifecycle callback interceptor methods for a lifecycle event run in the same Java call stack as the lifecycle callback method on the target class.
Coverage
No tests exist for this assertion
InvocationContext.proceed() will throw the same exception as any thrown by another lifecycle callback interceptor method or lifecycle callback method on the target class unless an interceptor further down the Java call stack has caught it and thrown a different exception.
A lifecycle callback interceptor method (other than a method on the target class or its superclasses) may catch an exception thrown by another lifecycle callback interceptor method in the invocation chain, and clean up before returning.
Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed() method.
The PreDestroy callbacks are not invoked when the target instance and the interceptors are discarded as a result of such exceptions: the lifecycle callback interceptor methods in the chain should perform any necessary clean-up operations as the interceptor chain unwinds.
Coverage
No tests exist for this assertion
The same InvocationContext instance will be passed to each interceptor method for a given target class method or lifecycle event interception. This allows an interceptor to save information in the context data property of the InvocationContext that can be subsequently retrieved in other interceptors as a means to pass contextual data between interceptors.
The contextual data is not sharable across separate target class method invocations or lifecycle callback events.
Coverage
No tests exist for this assertion
If interceptors are invoked as a result of the invocation on a web service endpoint, the map returned by getContextData() will be the JAX-WS MessageContext. The lifecycle of the InvocationContext instance is otherwise unspecified.
Coverage
No tests exist for this assertion
The getTimer() method returns the timer object associated with a timeout method invocation.
The getMethod() method returns the method of the target class for which the interceptor was invoked. For AroundInvoke methods, this is the method on the associated class; for lifecycle callback interceptor methods, getMethod() returns null.
The setParameters() method modifies the parameters used for the target class method invocation. Modifying the parameter value does not affect the determination of the method that is invoked on the target class.
The parameter types must match the types for the target class method, and the number of parameters supplied must equal the number of parameters on the target class method, or an IllegalArgumentException is thrown.
The proceed() method causes the invocation of the next interceptor method in the chain, or when called from the last AroundInvoke interceptor method, the target class method.
Coverage
No tests exist for this assertion
Interceptor methods must always call InvocationContext.proceed() or no subsequent interceptor methods or target class method or lifecycle callback methods will be invoked.
For lifecycle callback interceptor methods, if there is no callback method defined on the target class, the invocation of proceed() in the last interceptor method in the chain is a no-op, and null is returned.
Coverage
No tests exist for this assertion
If there is more than one such interceptor method, the invocation of proceed() causes the container to execute those methods in order.
Coverage
No tests exist for this assertion
Default interceptors may be defined to apply to a set of target classes.
The deployment descriptor is used to define default interceptors and their relative ordering.
The ExcludeDefaultInterceptors annotation or exclude-default-interceptors deployment descriptor element is used to exclude the invocation of default interceptors for a target class.
The default interceptors are invoked before any other interceptors for a target class. The interceptor-order deployment descriptor element may be used to specify alternative orderings.
An around-invoke interceptor method may be defined to apply only to a specific target class method invocation, independent of the other methods of the target class.
Likewise, an around-timeout interceptor method may be defined to apply only to a specific timeout method, independent of the other timeout methods of the target class.
Method-level interceptors are used to specify method interceptor methods or timeout interceptor methods. If an interceptor class that is only used as a method-level interceptor defines lifecycle callback interceptor methods, those lifecycle callback interceptor methods are not invoked.
Method-specific around-invoke and around-timeout interceptors can be defined by applying the Interceptors annotation to the method for which the interceptors are to be invoked, or by means of the interceptor-binding deployment descriptor element.
Method-level target class method interceptors are invoked in addition to any default interceptors and interceptors defined for the target class (and its superclasses). The deployment descriptor may be used to override this ordering.
The applicability of a method-level interceptor to more than one method of an associated target class does not affect the relationship between the interceptor instance and the target class - only a single instance of the interceptor class is created per target class instance.
The ExcludeDefaultInterceptors annotation or exclude-default-interceptors deployment descriptor element, when applied to a target class method, is used to exclude the invocation of default interceptors for that method.
The ExcludeClassInterceptors annotation or exclude-class-interceptors deployment descriptor element is used similarly to exclude the invocation of the class-level interceptors.
If default interceptors have also been defined for the bean class, they can be excluded for the specific method by applying the ExcludeDefaultInterceptors annotation on the method.
The deployment descriptor can be used as an alternative to metadata annotations to specify interceptors and their binding to target classes or to override the invocation order of interceptors as specified in annotations.
The interceptor deployment descriptor element is used to specify the interceptor methods of an interceptor class.
The interceptor methods are specified by using the around-invoke, around-timeout, post-construct and pre-destroy elements.
At most one method of a given interceptor class can be designated as an around-invoke method, an around-timeout method, a post-construct method, or pre-destroy method, regardless of whether the deployment descriptor is used to defined interceptors or whether some combination of annotations and deployment descriptor elements is used.
The interceptor-binding element is used to specify the binding of interceptor classes to target classes and their methods.
The target-name element must identify the associated target class or the wildcard value "*" (which is used to define interceptors that are bound to all target classes).
The interceptor-class element specifies the interceptor class. The interceptor class contained in an interceptor-class element must either be declared in the interceptor deployment descriptor element or appear in a least one @Interceptor annotation on a target class. The interceptor-order element is used as an optional alternative to specify a total ordering over the interceptors defined for the given level and above.
The exclude-default-interceptors and exclude-class-interceptors elements specify that default interceptors and class interceptors, respectively, are not to be applied to a target class and/or method.
The method-name element specifies the method name for a method-level interceptor; and the optional method-params elements identify a single method among multiple methods with an overloaded method name.
Interceptors bound to all target classes using the wildcard syntax "*" are default interceptors. In addition, interceptors may be bound at the level of the target class (class-level interceptors) or methods of the target class (method-level interceptors).
The binding of interceptors to classes is additive. If interceptors are bound at the class-level and/or default-level as well as at the method-level, both class-level and/or default-level as well as method-level interceptors will apply.
The deployment descriptor may be used to augment the interceptors and interceptor methods defined by means of annotations. When the deployment descriptor is used to augment the interceptors specified in annotations, the interceptor methods specified in the deployment descriptor will be invoked after those specified in annotations, according to the ordering specified earlier. The interceptor-order deployment descriptor element may be used to override this ordering.
The exclude-default-interceptors element disables default interceptors for the level at which it is specified and lower. That is, exclude-default-interceptors when applied at the class-level disables the application of default-interceptors for all methods of the class.
The exclude-class-interceptors element applied to a method, disables the application of class-level interceptors for the given method. Explicitly listing an excluded higher-level interceptor at a lower level causes it to be applied at that level and below.
It is possible to override the ordering of interceptors by using the interceptor-order element to specify a total ordering of interceptors at class-level and/or method-level. If the interceptor-order element is used, the ordering specified at the given level must be a total order over all interceptor classes that have been defined at that level and above (unless they have been explicitly excluded by means of one of the exclude- elements described above).
| Test Class | Test method |
|---|---|
broken (0) | |
incontainer-broken (0) | |
rewrite (0) | |
jboss-as-broken (0) | |
ri-broken (0) | |