Dne 7.1.2013 21:35, Mark Struberg napsal(a):
> 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!
The Interceptors spec uses the term "lifecycle callback interceptor
method" (see Interceptors for LifeCycle Event Callbacks):
"Lifecycle callback interceptor methods defined on an interceptor class
have the following signature:
void <METHOD>(InvocationContext)
Lifecycle callback interceptor methods defined on a target class have
the following signature:
void <METHOD>()"
So it's a different thing but has the same name :-)
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(a)redhat.com>
> To: Martin Kouba <mkouba(a)redhat.com>
> Cc: cdi-dev(a)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(a)yahoo.de>
>>>> To: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>