Chapter | Assertions | Testable | Total Tested | Total Tests | Tested (problematic) |
Tested (working) |
Coverage % |
---|---|---|---|---|---|---|---|
1 Overview | 0 | 0 | 0 | 0 | 0 | 0 | |
2 Interceptor Programming Contract | 91 | 69 | 67 | 98 | 0 | 67 | 97,10% |
3 Associating Interceptors using Interceptor Bindings | 39 | 32 | 30 | 56 | 0 | 30 | 93,75% |
4 Associating Interceptors using the Interceptors Annotation | 8 | 3 | 3 | 0 | 0 | 3 | 100,00% |
5 Interceptor Ordering | 22 | 10 | 10 | 33 | 0 | 10 | 100,00% |
Total | 160 | 114 | 110 | 187 | 0 | 110 | 96,49% |
Colour Key |
---|
Assertion is covered |
Assertion is not covered |
Assertion test is unimplemented |
Assertion is untestable |
An interceptor method may be defined on a target class or on an interceptor class associated with the target class.
Interceptor method may be defined on a target class.
Interceptor method may be defined on an interceptor class associated with the target class.
Coverage
Any number of interceptor classes may be associated with a target class.
Coverage
An interceptor class must not be abstract and must have a public no-arg constructor.
An around-invoke interceptor method, an around-timeout interceptor method, and lifecycle callback interceptor methods for different lifecycle events may be defined on the same interceptor class.
Coverage
An interceptor class may have superclasses.
Coverage
Interceptor methods and interceptor classes may be defined for a class by means of metadata annotations or, optionally, by means of a deployment descriptor.
Interceptors classes may be associated with the target class using either interceptor binding or the Interceptors annotation. Typically only one interceptor association type is used for any component.
A deployment descriptor may be used to specify the invocation order of interceptors or to override the order specified in metadata annotations. A deployment descriptor can be optionally used to define default interceptors or to associate interceptors with the target class. The EJB specification requires support for the ejb-jar.xml deployment descriptor and the CDI specification requires supports for the beans.xml deployment descriptor.
The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated.
Except as noted below, when the target instance is created, a corresponding interceptor instance is created for each associated interceptor class.
Coverage
These interceptor instances are destroyed if the target instance fails to be created or when it is removed.
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
When a AroundConstruct lifecycle callback interceptor is used, the following rules apply:
The AroundConstruct lifecycle callback is invoked after the dependency injection has been completed on instances of all interceptor classes associated with the target class.
Coverage
Injection of the target component into interceptor instances that are invoked during the AroundConstruct lifecycle callback is not supported.
The target instance is created and its constructor injection is performed, if applicable, when the last interceptor method in the AroundConstruct interceptor chain invokes the InvocationContext.proceed method. If the InvocationContext.proceed method is not invoked by an interceptor method, the target instance will not be created.
Coverage
The AroundConstruct interceptor method can access the constructed instance using the InvocationContext.getTarget method after the InvocationContext.proceed completes.
Coverage
Dependency injection on the target instance is not completed until after invocation of all interceptor methods in the AroundConstruct interceptor chain complete successfully.
The PostConstruct lifecycle callback chain for the target instance, if any, will be invoked after the dependency injection has been completed on the target instance.
An AroundConstruct lifecycle callback interceptor method should exercise caution when invoking methods of the target instance since its dependency injection may not have been completed.
With the exception of AroundConstruct lifecycle callback interceptors, all interceptor methods, including PostConstruct callbacks are invoked after dependency injection has been completed on both the interceptor instances and the target instance.
Coverage
PreDestroy callbacks, if any, are invoked before the target instance and all interceptor instances associated with it are destroyed.
An interceptor class shares the enterprise naming context of its associated target class. Annotations and/or XML deployment descriptor elements for dependency injection or for direct JNDI lookup refer to this shared naming context.
Coverage
Around-invoke and around-timeout interceptor methods run in the same Java thread as the associated target method.
Coverage
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. The InvocationContext object also provides metadata that enables interceptor methods to control the behavior of the interceptor invocation chain, including whether the next method in the chain is invoked and the values of its parameters and result.
Coverage
The InvocationContext object provides metadata that enables interceptor methods to control the behavior of the invocation chain.
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
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.
Coverage
No tests exist for this assertion
The getTarget method returns the associated target instance. For the AroundConstruct lifecycle callback interceptor method, getTarget returns null if called before the proceed method returns.
Coverage
The getTimer method returns the timer object associated with a timeout method invocation.
The getTimer method returns null for around-invoke methods and lifecycle callback interceptor methods.
Coverage
The getMethod method returns the method of the target class for which the interceptor was invoked.
Coverage
In a lifecycle callback interceptor for which there is no corresponding lifecycle callback method on the target class or in the AroundConstruct lifecycle callback interceptor method, getMethod returns null.
Coverage
The getParameters method returns the parameters of the method or constructor invocation. If the setParameters method has been called, getParameters returns the values to which the parameters have been set.
Coverage
The setParameters method modifies the parameters used for the target class method or constructor invocation. Modifying the parameter values does not affect the determination of the method or the constructor that is invoked on the target class. The parameter types must match the types for the target class method or constructor, and the number of parameters supplied must equal the number of parameters on the target class method or constructor, or the IllegalArgumentException is thrown.
Test setParameters method modifies the parameters used.
Coverage
Test invalid number of parameters.
Coverage
Test invalid parameter types.
Coverage
The proceed method causes the invocation of the next interceptor method in the chain, or, when called from the last around-invoke or around-timeout interceptor method, the target class method.
Test around-invoke interceptor method.
Coverage
Test around-timeout interceptor method.
Coverage
For AroundConstruct lifecycle callback interceptor methods, the invocation of the last interceptor method in the chain causes the target instance to be created.
Coverage
Interceptor methods must always call the InvocationContext.proceed method or no subsequent interceptor methods, target class method, or lifecycle callback methods will be invoked, or the target instance will not be created.
Coverage
If a method is of type void, the invocation of the proceed method returns null.
Coverage
For all other 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
In case of the PostConstruct interceptor, if there is no callback method defined on the target class, the invocation of InvocationContext.proceed method in the last interceptor method in the chain validates the target instance.
Interceptor methods are allowed to throw runtime exceptions or any checked exceptions that the associated target method allows within its throws clause.
Interceptor methods are allowed to catch and suppress exceptions and to recover by calling the InvocationContext.proceed method.
Interceptor method is allowed to recover by calling the InvocationContext.proceed method.
Coverage
The invocation of the InvocationContext.proceed method 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.
Coverage
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 business method invocations are denoted by the AroundInvoke annotation.
Around-invoke methods may be defined on interceptor classes and/or the target class and/or superclasses of the target class or the interceptor classes. However, only one around-invoke method may be defined on a given class.
Around-invoke methods can have public, private, protected, or package level access.
Test public level access.
Test private level access.
Coverage
Test protected level access.
Coverage
Test package level access.
Coverage
An around-invoke method must not be declared as abstract, final or static.
An around-invoke method can invoke any component or resource that the method it is intercepting can invoke.
Coverage
In general, an around-invoke method invocation occurs within the same transaction and security context as the method on which it is interposing. However, note that the transaction context may be changed by transactional interceptors in the invocation chain.
Test transaction context.
Coverage
Test security context.
Coverage
The AroundConstruct annotation denotes lifecycle callback interceptor methods that interpose on invocation of the target instance’s constructor.
The PostConstruct annotation denotes lifecycle callback interceptor methods that are invoked after the target instance has been constructed and dependency injection on that instance has been completed, but before any business method or other event can be invoked on the target instance.
Coverage
The PreDestroy annotation denotes lifecycle callback interceptor methods that interpose on the target instance’s removal.
Coverage
The AroundConstruct interceptor methods may be only defined on interceptor classes and/or superclasses of interceptor classes. The AroundConstruct callback should not be defined on the target class.
All other interceptor methods that interpose on the target instance lifecycle event callbacks can be defined on an interceptor class and/or directly on the target class.
Test PostConstruct interceptor method.
Coverage
Test PreDestroy interceptor method.
Coverage
A single lifecycle callback interceptor method may be used to interpose on multiple callback events.
Coverage
Lifecycle callback interceptor methods are invoked in an unspecified security context.
Lifecycle callback interceptor methods are invoked in a transaction context determined by their target class and/or method.
Coverage
AroundConstruct lifecycle callback interceptor methods may be defined on superclasses of interceptor classes. All other lifecycle callback interceptor methods may be defined on superclasses of the target class or of 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 otherwise be specified on a target class or interceptor class.
Coverage
Lifecycle callback interceptor methods can have public, private, protected, or package level access.
Test public level access.
Coverage
Test private level access.
Coverage
Test protected level access.
Coverage
Test package level access.
Coverage
A lifecycle callback interceptor method must not be declared as abstract, final or static.
Lifecycle callback interceptor methods may throw runtime exceptions, but not checked exceptions.
Coverage
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.
Coverage
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
Interceptor methods that interpose on timeout methods are denoted by the AroundTimeout annotation.
Around-timeout methods may be defined on interceptor classes and/or the target class and/or superclasses of the target class or interceptor classes. However, only one around-timeout method may be defined on a given class.
Test interceptor classes and/or superclasses.
Coverage
Test target class and/or superclasses.
Coverage
Around-timeout methods can have public, private, protected, or package level access. An around-timeout method must not be declared as abstract, final or static.
An around-timeout method can invoke any component or resource that its corresponding timeout method can invoke.
Coverage
An around-timeout method invocation occurs within the same transaction and security context as the timeout method on which it is interposing.
Test transaction context.
Coverage
Test security context.
Coverage
The InvocationContext.getTimer method allows an around-timeout method to retrieve the timer object associated with the timeout.
Coverage
Method-level interceptors are interceptor classes associated with a specific business or timeout method of the target class.
Coverage
Constructor-level interceptors are interceptor classes associated with a constructor of the target class.
Coverage
Only the interceptor methods of the interceptor class that are relevant for the context in which the interceptor is bound are invoked. For example, if the interceptor is bound only to a business method, any AroundConstruct, AroundTimeout, PostConstruct, or PreDestroy methods on the interceptor are not called.
Coverage
Method-level interceptors may not be associated with a lifecycle callback method of the target class.
The same interceptor may be applied to more than one business or timeout method of the target class.
Coverage
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.
Coverage
Interceptor bindings are intermediate annotations that may be used to associate interceptors with any component that is not itself an interceptor.
An interceptor binding type is a Java annotation defined as Retention(RUNTIME). Typically an interceptor binding is defined as Target({TYPE, METHOD, CONSTRUCTOR}) or any subset of valid target types.
Coverage
An interceptor binding type may be declared by specifying the InterceptorBinding meta-annotation.
Coverage
An interceptor binding type may declare other interceptor bindings.
Coverage
Interceptor bindings are transitive - an interceptor binding declared by an interceptor binding type is inherited by all components and other interceptor binding types that declare that interceptor binding type.
Coverage
An interceptor binding type can only be applied to an interceptor binding type defining a superset of it's target types. For example interceptor binding types declared Target(TYPE) may not be applied to interceptor binding types declared Target({TYPE, METHOD}).
An extension specification may define other sources of interceptor bindings, such as via a CDI stereotype.
Coverage
The interceptor bindings of an interceptor are specified by annotating the interceptor class with the binding types and the Interceptor annotation and are called the set of interceptor bindings for the interceptor.
Multiple interceptors may declare the same interceptor bindings.
Coverage
An extension specification may define other ways of declaring an interceptor.
Coverage
No tests exist for this assertion
If an interceptor does not declare an Interceptor annotation, it could be bound to components using Interceptors annotation or a deployment descriptor file.
Coverage
No tests exist for this assertion
All interceptors declared using the Interceptor annotation should specify at least one interceptor binding. If an interceptor declared using the Interceptor annotation does not declare any interceptor binding, non-portable behavior results.
With the exception of AroundConstruct lifecycle callback interceptors, an interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as Target(TYPE).
An interceptor may be bound to a component by annotating the component class, a method, or constructor of the component class, with the interceptor binding type.
Test a method.
Coverage
Test a constructor.
Coverage
A component class, method, or constructor of a component class may declare multiple interceptor bindings.
Test a method.
Coverage
Test a constructor.
Coverage
The set of interceptor bindings for a method or constructor are those declared at class level combined with those declared at method or constructor level.
An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass.
Test a constructor.
Test a method.
Coverage
An extension specification may define additional rules for combining interceptor bindings, such as interceptors defined via a CDI stereotype.
If the component class declares or inherits a class level interceptor binding, it must not be declared final, or have any non-static, non-private, final methods. If a component has a class-level interceptor binding and is declared final or has a non-static, non-private, final method, the container automatically detects the problem and treats it as a definition error.
If a non-static, non-private method of a component class declares a method level interceptor binding, neither the method nor the component class may be declared final. If a non-static, non-private, final method of a component has a method level interceptor binding, the container automatically detects the problem and treats it as a definition error.
The process of matching interceptors to a certain lifecycle callback method, timeout method, business method or a constructor of a certain component is called interceptor resolution.
For a lifecycle callback, the interceptor bindings include the interceptor bindings declared or inherited by the component at the class level, including, recursively, interceptor bindings declared as meta-annotations of other interceptor bindings.
Coverage
For a business method, timeout method, or constructor the interceptor bindings include the interceptor bindings declared or inherited by the component at the class level, including, recursively, interceptor bindings declared as meta-annotations of other interceptor bindings, together with all interceptor bindings declared on the constructor or method, including, recursively, interceptor bindings declared as meta-annotations of other interceptor bindings.
Test a business method.
Test a timeout method.
Coverage
Test a constructor.
Coverage
An interceptor is bound to a method or constructor if:
The method or constructor has all the interceptor bindings of the interceptor. A method or constructor has an interceptor binding of an interceptor if it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member. An extension specification may further refine this rule. For example the CDI specification adds the javax.enterprise.util.Nonbinding annotation, causing member values to be ignored by the resolution process.
Coverage
The interceptor intercepts the given kind of lifecycle callback or business method.
Coverage
The interceptor is enabled.
Coverage
An interceptor class may specify multiple interceptor bindings.
Coverage
Interceptor binding types may have annotation members.
Annotation member values are compared using the equals method.
Coverage
Array-valued or annotation-valued members of an interceptor binding type are not supported. An extension specification may add support for these member types. For example the CDI specification adds the javax.enterprise.util.Nonbinding annotation, allowing array-valued or annotation-valued members to be used on the annotation type, but ignored by the resolution process.
Coverage
If the set of interceptor bindings of a component class or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error.
Coverage
The Interceptors annotation can be used to denote interceptor classes and associate one or more interceptor classes with a target class, and/or one or more of its methods, and/or a constructor of the target class.
Coverage
If multiple interceptors are defined for the target class in the Interceptors annotation, they are invoked in the order in which they are specified. See Chapter 5 for the rules on interceptors ordering.
If a deployment descriptor is supported, it can be used to associate interceptor classes with the target class, and/or methods, and/or a constructor of the target class and specify the order of interceptor invocation or override metadata specified by annotations.
Method-level 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.
Coverage
Constructor-level interceptors can be defined by applying the Interceptors annotation to the constructor for which the interceptors are to be invoked.
Coverage
If more than one constructor- or method-level interceptor is defined for a target class constructor or method, the interceptors are invoked in the order specified. Constructor- and method-level interceptors are invoked in addition to any default interceptors and interceptors defined for the target class (and its superclasses).
Default interceptors are interceptors that apply to a set of target classes. If a deployment descriptor is supported, it may be used to define default interceptors and their relative ordering.
The ExcludeDefaultInterceptors annotation is used to exclude the invocation of default interceptors for a target class, or when applied to a target class constructor or method, is used to exclude the invocation of default interceptors for that constructor or that method.
Associating interceptors with the target class or method of the target class using the Interceptors annotation enables them for the target class, a method, or a constructor of the target class. The order in which they are invoked is determined by the order in which they are specified in the annotation.
Coverage
Interceptors declared using interceptor bindings are enabled and ordered using the Priority annotation or the beans.xml deployment descriptor.
An extension specification may define alternative mechanisms to enable and order interceptors.
For the same interceptor method type, interceptors declared using interceptor bindings are called after interceptors declared using the Interceptors annotation (or using the corresponding element of a deployment descriptor) and before an interceptor method of the same interceptor type declared on the target class or any superclass of the target class.
The InvocationContext object enables interceptor methods to control the behavior of the invocation chain, including whether the next method in the chain is invoked and the values of its parameters and result.
Interceptor methods declared on the target class or its superclasses are invoked in the following order:
If a target class has superclasses, any interceptor methods defined on those superclasses are invoked, most general superclass first.
Coverage
The interceptor method, if any, on the target class itself is invoked.
Coverage
If an interceptor method is overridden by another method (regardless of whether that method is itself an interceptor method), it will not be invoked.
Test business method interceptor method.
Coverage
Test lifecycle interceptor method.
Coverage
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.
Coverage
An interceptor bound to a component, a component method, or constructor using interceptor binding may be enabled for the entire application by applying the Priority annotation, along with a priority value, on the interceptor class.
Interceptors with smaller priority values are called first.
If more than one interceptor has the same priority, the relative order of these interceptor is undefined.
The Priority annotation is ignored on interceptors bound to a component using the Interceptors annotation.
Extension specifications may define other ways of assigning priorities to an interceptor.
If multiple business or timeout method interceptor methods are defined for a target class or multiple callback interceptor methods are defined for a lifecycle event for a target class using the Interceptors annotation, the following rules govern their invocation order for each interceptor type. A 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 a 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 interceptor methods defined on those interceptor classes are invoked in the same order as the specification of the interceptor classes in the Interceptors annotation.
Coverage
If an interceptor class itself has superclasses, the interceptor methods are invoked according to the rules described in the section 5.2.2.
After the interceptor methods defined on interceptor classes have been invoked, then if any constructor- or around-invoke or around-timeout method-level interceptors are defined for the target class constructor or method that is to be invoked, the corresponding 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 constructor or method.
And then interceptors declared on the target class or its superclasses are invoked according to the rules described in the section 5.2.1.
The ExcludeClassInterceptors annotation can be used to exclude the invocation of the class-level interceptors.
Coverage
Test Class | Test method |
---|---|
rewrite (0) |