Re: [interceptors-dev] Multiple @AroundInvoke methods in the same interc

["Tracy Burroughs" <tkb@xxxxxxxxxx>]

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).

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.

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.

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.

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.


-- Tracy Burroughs (tkb@xxxxxxxxxx)
-- WebSphere Application Server Development
-- IBM Rochester,  Dept WG8A    H315/050-2
-- 2800 37th Street NW, Rochester MN 55901-4441


"interceptors-dev" <interceptors-dev-bounces@xxxxxxxxxxx>
wrote on 04/27/2021 10:54:29 AM:

> From: Laird Nelson <ljnelson@xxxxxxxxx>
> To: interceptors developer discussions
<interceptors-dev@xxxxxxxxxxx>
> Date: 04/27/2021 10:54 AM
> Subject: [EXTERNAL] Re: [interceptors-dev]
Multiple @AroundInvoke 
> methods in the same interceptor class?
> Sent by: "interceptors-dev"
<interceptors-dev-bounces@xxxxxxxxxxx>
> 
> On Mon, Apr 26, 2021 at 10:36 PM David Blevins 
> <dblevins@xxxxxxxxxxxxx> wrote: 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 
> On Mon, Apr 26, 2021 at 10:36
PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> 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_______________________________________________
> interceptors-dev mailing list
> interceptors-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/interceptors-dev