[cdi-dev] intercepted private @PostConstruct method behaviour?
Mark Struberg
struberg at yahoo.de
Mon Jan 7 15:35:16 EST 2013
> in this case there are two lifecycle callback
> interceptor methods
Well, it is not 100% to the point I fear. At least not if we stick to the defined terms
The point is that a @PostConstruct on a bean is NOT a lifecycle callback INTERCEPTOR but a lifecycle callback method.
And the @PostConstruct on the Interceptor must have the InvocationContext parameter. So this is essentially a different thing!
But after reading 7.2 again I agree that @PostConstruct, etc methods automatically becomes a 'business method' if manually invoked.
LieGrue,
strub
>________________________________
> From: Pete Muir <pmuir at redhat.com>
>To: Martin Kouba <mkouba at redhat.com>
>Cc: cdi-dev at lists.jboss.org
>Sent: Monday, January 7, 2013 4:32 PM
>Subject: Re: [cdi-dev] intercepted private @PostConstruct method behaviour?
>
>I think Martin is right.
>
>On 7 Jan 2013, at 08:40, Martin Kouba wrote:
>
>> Hi,
>>
>> my interpretation is that in this case there are two lifecycle callback
>> interceptor methods. The first on the target class (MyService). The
>> other one on the interceptor class (TransactionalInterceptor). Each time
>> a new contextual instance of MyService is initialized all the lifecycle
>> callback interceptor methods are invoked according to the rules defined
>> in the Interceptors spec (Multiple Callback Interceptor Methods for a
>> Life Cycle Callback Event) -> TransactionalInterceptor first.
>>
>> With regards the manual invocation of doTheInit (via a contextual
>> reference to the bean):
>> * according to the CDI spec (7.2 Container invocations and
>> interception), such an invocation will result in a regular business
>> method invocation (aroundInvoke intercepted, decorated, etc.)
>> * and again both lifecycle callbacks will only be invoked if a new
>> contextual instance of MyService is initialized
>>
>> Re TCK - raise an issue please :-)
>>
>> Martin
>>
>>
>> Dne 5.1.2013 15:24, Mark Struberg napsal(a):
>>>
>>>
>>> I guess I found the answer by studying the interceptors spec. It states that
>>>
>>> "The PostConstruct and PreDestroy, annotations are used to define an interceptor
>>> method for a lifecycle callback event."
>>>
>>> I assume that those are really only meant for 'lifecycle callback events' and must _not_ get invoked if they got called manually.
>>>
>>> Thus postConstructInterception will also get called for the private method but NOT for a manual invocation if the doTheInit would be public.
>>>
>>> Is this interpretation correct?
>>> Can we have a TCK for it? :D
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> ----- Original Message -----
>>>> From: Mark Struberg <struberg at yahoo.de>
>>>> To: cdi-dev <cdi-dev at lists.jboss.org>
>>>> Cc:
>>>> Sent: Saturday, January 5, 2013 2:56 PM
>>>> Subject: [cdi-dev] intercepted private @PostConstruct method behaviour?
>>>>
>>>> Hi folks!
>>>>
>>>> What happens if I have a
>>>>
>>>>
>>>> @Transactional
>>>> public class MyService {
>>>> @PostConstruct
>>>> private void doTheInit() {...}
>>>>
>>>> Where the interceptor looks like
>>>> @Interceptor @Transactional
>>>> public class TransactionalInterceptor {
>>>>
>>>> @PostConstruct
>>>> public void postConstructInterception(InvocationContext ic) {..}
>>>>
>>>>
>>>>
>>>> Question a.) does the @Transactional interceptor still apply to the _private_
>>>> doTheInit() method?
>>>>
>>>> Question b.) consider the doTheInit() method being changed to public and it will
>>>> get invoked by a user. Does the postConstructInterception still get invoked? Or
>>>> must it only get invoked for _real_ PostConstruct actions triggered by the
>>>> container?
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
More information about the cdi-dev
mailing list