This has to do with section 5.2.2 Invocation Order of Interceptors with Superclasses:
"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."

Let's consider a simple scenario with two interceptors bound to a class, one interceptor class extends the other:

class A {
@AroundInvoke
void interceptA() {}
}

class B extends A {
@AroundInvoke
void interceptB() {}
}

@Interceptors(B.class, A.class)
class Foo {
void foo() {}
}

...
Foo foo = new Foo();
foo.foo(); // "LINE L" - interceptor methods get invoked ...

(1) I assume that (on "LINE L") around-invoke methods should be invoked in this order: A.interceptA(), B.interceptB(), A.interceptA().

(2) However, other interpretation is that when target instance's method is called (foo.foo()), interceptor's method (A.interceptA()) will be called no more than once, resulting in invocation order: A.interceptA(), B.interceptB(). I.e. the rule in section 5.2.2 "overrides" rules about order in which the interceptor methods would be called otherwise (e.g. the rule "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." from bullet 3 in section 5.5).

I think this should be clarified.

This problem affects all types of interceptors (business method / lifecycle event callback / ...) and all types of binding an interceptor to a component (using @interceptors annotation / interceptor bindings and @priority annotation / deployment descriptor).

Affected Versions

[1.2]