Hi Jeremy,
On 2/15/13 11:53 AM, Jeremy Bauer wrote:
> Hi Marina,
>
> Thanks for your reply.
>
> Re: #2 From an EJB perspective, this still doesn't seem problematic.
> For example, I would expect the following to work, because the @EJB
> injection does not directly inject a target instance.
>
> @Stateless @Interceptors(Int1.class) public class A { }
> public class Int1 { @EJB A field; }
>
> It would be the actual invocation of a method on Int1.field in an
> AroundConstruct that would problematic. I can see where just adding
> the basic restriction will eliminate potential issues, though.
For a SLSB - yes. But what if it's a singleton or a SFSB?
>
> Re: #3 please add this to javadoc and/or spec
I did.
>
> Re: #7 For example, if there are two interceptors, each with setter
> injection, is there a required order for {construct Int1, construct
> Int2, inject Int1, inject Int2, call Int1.aroundConstruct, call
> Int2.aroundConstruct, construct target instance}? Or is there freedom
> to create/inject interceptor instances in any order, so long as the
> aroundConstruct for a specific interceptor is called after injection
> for that specific interceptor?
Draft3 says: "The AroundConstruct lifecycle callback is invoked after
the dependency injection has been completed on instances of all
interceptor classes associated with the target class."
Does it make sense?
thanks,
-marina
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Cc: Jeremy Bauer/Rochester/IBM_at_IBMUS, users_at_interceptors-spec.java.net
> Date: 02/13/2013 02:27 PM
> Subject: [jsr345-experts] Re: Interceptors spec 1.2 DRAFT2 is
> available for review
> ------------------------------------------------------------------------
>
>
>
> 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>_
> <mailto:marina.vatkina_at_oracle.com>
> To: _jsr345-experts_at_ejb-spec.java.net_
> <mailto:jsr345-experts_at_ejb-spec.java.net>,
> _users_at_interceptors-spec.java.net_
> <mailto: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
>
>
>