> On Feb 23, 2016, at 5:54 PM, Linda DeMichiel <linda.demichiel_at_oracle.com> wrote:
>
> One of the things I've been working on lately is a cleanup of the
> Interceptors spec.
>
> The intent here is not to change the semantics of the Interceptors 1.2
> spec, but to clarify a number of areas that appeared to me somewhat
> confusing. I've also flagged several open issues that we need to
> either resolve or explicitly specify as portability concerns.
>
> I would appreciate if you would read the document in its entirety, and
> weigh in on the open issues. Also, if you believe that I have
> inadvertantly changed the semantics of the spec, please let me know,
> as that was not my intent.
>
> You can download the document here: https://java.net/projects/javaee-spec/downloads/download/Interceptors021716.pdf
Hi Linda,
I think your draft looks good, and no new semantics seem to stick out. Here is my feedback:
2.5. OPEN ISSUE: Should the above statement be extended to constructors as well? I.e., should the specifi- cation state the following?: Interceptor methods are allowed to throw runtime exceptions or any checked exceptions that the associated target method or constructor allows within its throws clause.
Yes, I think thats consistent, and intuitive.
2.7.1 OPEN ISSUE: What if an around-construct method intercepts a constructor that throws a checked exception? Is the around-construct interceptor method allowed to throw checked exceptions? Is it allowed to catch/ignore them?
Yes, it should be allowed to throw a checked exception. That exception will likely end up being wrapped, but there is no harm in that.
Yes, it should be allowed to catch and ignore an exception from other interceptors or the target itself. For example, it might retry the construction.
2.10 OPEN ISSUE: What about annotations to define default interceptors? I.e., should we state the follow- ing?: An extension specification may support the use of a deployment descriptor or annotations to define default interceptors and their relative ordering.
Yes.
3.2 With the exception of around-construct lifecycle callback interceptors, interceptors for lifecycle call- backs may only declare interceptor binding types that are defined as Target(TYPE).
OPEN ISSUE: What if that same interceptor contains an around-invoke method? Does that same restriction apply? (It seems too restrictive.)
I agree that this is too restrictive. I think its a dated notion that traces back to when there was a clear difference between lifecycle and invocation method interceptors.
3.3 OPEN ISSUE: What is meant by “of the same type”? Does this include annotation members? Need to clarify.
I think it’s meant to replace any other occurrence of that binding type regardless of member value. Otherwise you can end up with conflicting bindings.
4.0 OPEN ISSUE: The above point requires clarification with regard to applying the Inter- ceptors annotation at constructor-level to a superclass constructor. What should happen when an instance of the target class is created? Should the superclass interceptor be invoked or not?
Unless I missed something, I think you already answer this question in the content you have below this question.
5.2 OPEN ISSUE: What happens if a superclass of the target class specifies the Inter- ceptors annotation? Should those interceptors also be run? Previous versions of this specification did not state so, and the RI is inconsistent in its treatment of this case.
I think we should aim for consistency here, the superclass class-level interceptors should also be run.
5.2.1 OPEN ISSUE: The following rules are currently observed by both the EJB and the CDI specifications for interceptors defined/enabled by deployment descriptors. Should they be required to apply to exten- sion specifications?
I’m not sure on this one. While these are sensible requirements, Is it necessary to close the door completely here?
5.3 OPEN ISSUE: The intent here needs to be clarified. The javadocs seem to imply that Exclude- ClassInterceptors is not restricted to interceptors defined via Interceptors.
I think your clarification below looks good.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat