>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."
Adding this does not hurt, but I'm not sure if it is really needed.
The old 1.1 spec already said in "Interceptor Life Cycle":
"Both the interceptor instance and the target instance are created before any PostConstruct callbacks
are invoked."
'are created' imo also means that all their injections already got processed. Other paragraphs seem to support this interpretation.
LieGrue,
strub
>________________________________
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>To: jsr345-experts_at_ejb-spec.java.net
>Cc: Jeremy Bauer <jrbauer_at_us.ibm.com>
>Sent: Friday, February 15, 2013 9:20 PM
>Subject: [ejb-spec users] [jsr345-experts] Re: Interceptors spec 1.2 DRAFT2 is available for review
>
>
>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>
>>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
>>
>>
>>
>>
>
>
>