I think this is outside the spec, but I actually don't think it's a bad feature.
Right; no value judgments here either. But the specification wording stopped me: it is remarkable in its exacting language. "Up to one" of something is basically a MUST rather than a SHOULD. The specification also is quite clear elsewhere when it expects to be extended; that language is missing here. For example, this sentence could have been stylistically compatible with the rest of the document by reading something like: "Specifying more than one interceptor method type may result in undefined behavior" or "extension specifications may relax this restriction" etc. But it is not written in this way.
I am curious mostly because in my experience when you run into language like this it is because there is an edge case that the language is explicitly designed to prevent. It sounds like whatever that edge case is or was, it's gone now and has been for many years.
The real trick is sensible rules around ordering so it could actually be tested in a JVM-independent way.
And the specification has those rules at its disposal, yes? It talks both about JVM-specific features (such as
@Priority) and then also spells out
how extension specifications do this with a deployment descriptor. Nevertheless it stuck with the "up to one" language.
Anyway this was exactly why I was given pause: all the tools (and more importantly the language conventions within the document) are already there to support multiple @AroundInvoke methods and yet the spec says very carefully that there can be only up to one. Sounds like the reasoning for this restriction is lost to the mists of time.
Best,
Laird
