users@interceptors-spec.java.net

[interceptors-spec users] Re: [jsr345-experts] Re: Interceptors spec 1.2 DRAFT2 is available for review

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Wed, 13 Feb 2013 12:25:19 -0800

Hi Jeremy,

Thanks for the review.

On 2/13/13 11:08 AM, Jeremy Bauer wrote:
> Hi Marina,
>
> Some feedback regarding @AroundConstruct in draft 2.
>
> 1. Some non-normative use-cases/examples would be helpful.

The intent is to be used by BV, and to much lesser extent by regular
developers. But I can try to come up with something if you feel it's needed.

>
> 2. What is the intent of this restriction: "Injection of the target
> component into interceptor instances that are invoked during the
> AroundConstruct lifecycle callback, is not supported."? The injection
> of a target wrapper/proxy into the interceptor shouldn't be a problem.
> Is primarily to avoid invocation of the target in the interceptor,
> which could result in a loop?

It's just the problem of when will this happen? After the instance is
created or later on, when its injection is completed? Again, as the
intent for this interceptor is not for the general use, it seemed as a
reasonable restriction.

>
> 3. What is the behavior of InvocationContext.getTarget prior to the
> final proceed()? Does it return null, does it throw
> IllegalStateException, or ?

null should be fine.
>
> 4. The phrase "should not invoke any business methods of the target
> instance" seems questionable, since the actual bean instance is
> returned, not an ejb wrapper/proxy. Is the intent to restrict what I
> mentioned in #2? Perhaps it should say "Interceptors should be
> careful to avoid calling methods on the target instance that might
> rely on state that has not been initialized since injection and
> @PostConstruct lifecycle callback methods have not been called".

Thanks. Will use it.
>
> 5. What happens if an @AroundConstruct interceptor doesn't call
> proceed()? Presumably this is an error. Is it up to the individual
> specs (e.g., EJB would throw EJBException) to define the behavior?

The instance won't be created and an exception will be thrown. I'll
update the spec.
>
> 6. This statement seems to have an incorrect implication:
>
> "If the AroundConstruct lifecycle callbacks are NOT associated with
> the target instance, all interceptor methods, including PostConstruct
> callbacks, if any, are invoked only after dependency injection has
> been completed on both, the interceptor instances and the target
> instance. [1]."
>
> The 'NOT' in this position implies that if AroundConstruct IS present
> then PostConstruct might be called before dependency injection, which
> is not correct. Something like "all interceptor methods except
> AroundConstruct callbacks are invoked only after dependency injection
> has been completed" eliminates that implication.

OK. Thanks.
>
> 7. Do interceptors need to be injected as proceed() is called, or is
> there freedom to inject them all, then invoke them all?

Interceptors get injected with dependencies?Do you mean this: "The
AroundConstruct lifecycle callback is invoked after the dependency
injection has been completed on the interceptor instance."? It should be
"instances".


> If not defined, each vendor could choose a different scheme, leading
> to differences in behavior. For example, complete
> construction+injection could lead to an early injection failure, while
> lazy construction+injection of interceptors may avoid an up-front
> injection failure and throw some other exception in the middle of the
> invocation chain.

Thanks again,
-marina

>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net, users_at_interceptors-spec.java.net,
> Date: 02/11/2013 02:20 PM
> Subject: [jsr345-experts] Interceptors spec 1.2 DRAFT2 is available
> for review
> ------------------------------------------------------------------------
>
>
>
> Experts,
>
> You can now review the 2nd draft of the Interceptors spec. This version
> incorporates most of the review comments and the AroundConstruct
> interceptor. The full list of changes is below (the change log at the
> end of the document is an accumulative list).
>
> The draft:
> http://java.net/projects/interceptors-spec/downloads/download/interceptor-1-2-dr2.pdf
> The diff from draft1:
> http://java.net/projects/interceptors-spec/downloads/download/interceptor-1-2-dr2-diff.pdf
>
> Please review it (AroundConstruct) in particular ASAP.
>
> Pete, please forward it to the CDI EG.
>
> The list of changes as found in the revision history:
>
> - Fixed page numbers in the book
> - Minor editorial changes
> - Moved Section 5.6 to the end of Chapter 5
> - Moved rule on invocation order of interceptors with superclasses to
> Section 5.3
> - Replaced rules on the Nonbinding annotation with references to the CDI
> spec
> - Clarified that an around-invoke interceptor method, around-timeout
> interceptor method, and lifecycle callback interceptor methods for
> different lifecycle events may be defined on the same interceptor class
> - Added the AroundConstruct lifecycle callback interceptor
> - Extended InvocationContext with getConstructor method; adjusted rules
> on the InvocationContext.getTarget return value, and
> InvocationContext.proceed result
> - Added notes to the around-invoke and around-timeout about the throw
> Exception clause in their signatures
> - Added a not that transaction context of interceptors may be changed by
> transactional interceptors in the invocation chain
> - Explained how interceptors are enabled
>
> Happy reading,
> -marina
>
>