[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