On 18 Feb 2013, at 20:24, Mark Struberg <struberg_at_yahoo.de> wrote:
>
>
> Oh, @AroundConstruct, sorry did wrongly ready @PostConstruct - my bad!
>
> Pete, what do we do right now in CDI-1.0 with @Inject constructors of the intercepted beans? Imo 5.5.1 defines that Bean Constructors (definition in 3.7) will get invoked first, and only after that all injected fields and then injected methods will get served.
>
>
> Thus the final order would be
>
> a.) create all interceptors, inject all the fields/methods in interceptors
> b.) call the Bean Constructor (or the default ct?) through any existing @AroundConstruct
> c.) inject fields in the intercepted bean
> d.) inject methods in the intercepted bean
> e.) invoke @PostConstruct
> f.) publish the instance to the Context
+1
I *think* we have this order (still) specified, but please say if Marina and I screwed it up somehow!
>
>
> right?
>
> LieGrue,
> strub
>
>
>> ________________________________
>> From: Peter Muir <pmuir_at_bleepbleep.org.uk>
>> To: Mark Struberg <struberg_at_yahoo.de>
>> Cc: "marina.vatkina_at_oracle.com" <marina.vatkina_at_oracle.com>; ejb-users <users_at_ejb-spec.java.net>; Jeremy Bauer <jrbauer_at_us.ibm.com>
>> Sent: Monday, February 18, 2013 6:55 PM
>> Subject: Re: [ejb-spec users] [jsr345-experts] Re: Interceptors spec 1.2 DRAFT2 is available for review
>>
>>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>