On 16 Feb 2013, at 10:16, Mark Struberg <struberg_at_yahoo.de> wrote:
>
>> 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.
But this doesn't cover @AroundConstruct?
>
> 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
>>>
>>>
>>>
>>>
>>
>>
>>