What is the scope of a setParameters(Object[]) invocation in Jakarta Interceptors 2.1?
Suppose I'm "in" the following (outermost) interceptor method:
// Pseudocode; eliminating all exception handling and other bits for brevity
void intercept0(InvocationContext ic0) {
assert Objects.equals(new Object[] { "a" }, ic0.getParameters()); // let's say, for this example
ic0.proceed(); // see below; results in intercept1(InvocationContext) firing
Object[] p0 = ic0.getParameters(); // see below; what's p0's value?
}
And suppose that the proceed() call above results in this (innermost) interceptor method firing next:
void intercept1(InvocationContext ic1) {
ic1.setParameters(new Object[] { "b" }); // does this affect p0 above?
ic1.proceed(); // no further interception after this point
}
What is p0's 0th element's guaranteed value (assuming no further interception)? Is it:
(a) "a"
(b) "b"
(c) undefined; depends on the implementation
The specification text itself is mostly silent. The javadocs for getParameters() say: "If setParameters(java.lang.Object[]) has been called, getParameters returns the values to which the parameters have been set."
That suggests (reasonably, I might add), but does not explicitly require, (b).
Was the javadoc text intended to require (b) (even when ic0 != ic1)? I assume yes.
I assume as well that the effects of directly mutating the contents of the array are undefined (i.e. perhaps they are local to ic0 or ic1, or perhaps they affect both). Is that in fact true?
More generally, therefore: must a given InvocationContext, in the context of a given interceptor method invocation, behave, with regards to its readable state, as if ic0 == ic1, even when an implementation does not implement things this way? I assume yes.
A related (believe it or not) question: may a client of InvocationContext call proceed() twice? Is the terminal constructor or method guaranteed by the specification to "fire" twice? I assume yes but I haven't tried it across multiple implementations to know for sure.
Thanks,
Laird
