I believe the limitation
of one @AroundInvoke per class was/is very intentional with the primary
purpose of defining very clear interceptor ordering. If multiple
exist on a single class, then the default order they would run would need
to be clear, and the ability to configure specific ordering would need
to be enhanced. For example, the following configuration would not
support his:
<interceptor-order>
<interceptor-class>MLInterceptor2</interceptor-class>
<interceptor-class>MLInterceptor1</interceptor-class>
<interceptor-class>CLInterceptor2</interceptor-class>
<interceptor-class>CLInterceptor1</interceptor-class>
</interceptor-order>
There is no mechanism to specify methods, only interceptor classes. My
guess would be that the extra complexity required to support multiple methods
per class did not seem worth the cost... at the time the specification
was written (15 years ago).
OK, so the "root cause" is: the XML speaks of classes only; interceptors are fundamentally methods; therefore ordering would be imprecise; so there you go. Thanks.
Keep in mind that this portion of the Interceptors specification was developed
quite some time ago, before there were any JVM-specific features that you
mention.
As to why this very clear limitation is not enforced by Weld; well that
is most likely due to the origin of this part of the Interceptors specification.
Much of the content of the Interceptors specification originated in the
EJB specification, before being split off into an independent specification.
And, the EJB specification, like many older Java EE specifications
was written with the philosophy that enforcement of "configuration"
problems in an application were strictly the responsibility of the Vendor
implementation. Every vendor implementation could choose to enforce
configuration errors (or not enforce them) as they felt appropriate.
…because application server vendors were supposed to compete on configuration and vendor extensions and tooling that never materialized and the like. Yep; I remember those days!
Also keep in mind that the TCKs developed for most older Java EE
applications would NOT address this. The TCKs for older Java EE spec
levels did not cover invalid configurations; why test something that is
not a valid Java EE application? If a Java EE specification did not
very clearly state that an error should be raised at some point, then there
would be no test in the TCK to cover it.
That is a very interesting stance to take indeed and explains a lot. Thanks.
So, while the specification is very clear this is not a valid configuration,
it does not clearly state what error should be raised nor when, so will
not be covered by the TCK. Therefore implementations would be free
to not enforce the specification behavior and still pass the TCK. Weld
is thus able to pass the TCK and provide this capability as an extension
to the specification.
Note that other vendor implementations may not support his. Applications
written to use multiple @AroundInvoke methods on a class would not be portable
to other vendor implementations. For example, I can confirm that
Open Liberty will definitely throw an exception when an application with
such a configuration is started.
Thanks; this is exactly the sort of thing I was looking for.
While relaxing this limitation might appear trivial in relation to the
way Interceptors integrate with the CDI specification, it would be more
complex when it comes to other specifications, such as the EJB specification
that allows such interceptors to be configured in XML, and would require
enhancements to such XML to account for methods.
Right; in keeping with your first statement. Thanks again for this beautifully clear, insightful response. Perhaps there should be a footnote (or 12 :-)) somewhere in the specification indicating some portion of this.
Also, and this is a larger issue for a different mailing list, the absence of language in this specification and others talking about "the philosophy that enforcement of 'configuration' problems in an application were strictly the responsibility of the Vendor implementation" seems problematic (and I understand it's larger than just this specification in particular): perhaps this is a good example of "tribal knowledge" that isn't actually captured anywhere in the documents of interest?
Best,
Laird
