[cdi-dev] Lifecycle Callback Interceptor and @Target "METHOD"

Jozef Hartinger jharting at redhat.com
Wed Jun 19 03:55:24 EDT 2013


The restriction is not new. It's been around since CDI 1.0 which says:

"An interceptor for lifecycle callbacks may only declare interceptor 
binding types that are defined as @Target(TYPE). If an
interceptor for lifecycle callbacks declares an interceptor binding type 
that is defined @Target({TYPE, METHOD}), the container
automatically detects the problem and treats it as a definition error."

For EE7 this was just moved to the interceptors spec and adjusted to 
count with @AroundConstruct.

On 06/18/2013 10:15 PM, Jens Schumann wrote:
> Hi all,
>
> (I have been way too busy to comment on this, and I have the impression
> that my WELD bug report was too late already).
>
> Jozef closed my bug report [1] stating that the new interceptor spec now
> contains the following sentence:
>
> "With the exception of AroundConstruct lifecycle callback interceptors, an
> interceptor for lifecycle callbacks may only declare interceptor binding
> types that are defined as Target(TYPE)."
>
> >From what I understood this sentence went into the interceptor spec
> because of JIRA issue "Recent changes to how lifecycle event interceptors
> are bound introduce questionable behavior" [2]. What is interesting here
> is that a questionable behavior led to a strict ban instead of a "non
> portable" declaration. I know this is the wrong mailing list - but
> wouldn't you expect a non portable declaration in such a situation?
>
>
> What is more frustrating here is that the spec prohibits a feature that
> works with both WELD and OWB.
>
> In my case the new interceptor spec now requires two annotations if I want
> to apply the same behavior to a lifecycle callback AND a business method.
>
> Since the new interceptor spec is a maintenance release it should be easy
> to fix, shouldn't it? ;)
>
> Jens
> [1] https://issues.jboss.org/browse/WELD-1416
> [2] https://java.net/jira/browse/INTERCEPTORS_SPEC-20
>
> Am 11.06.13 15:56 schrieb "Martin Kouba" unter <mkouba at redhat.com>:
>
>> Hi Radim,
>>
>> no, adding @AroundConstruct callback does not help. The statement Jozef
>> is referencing means: An interceptor for @PostConstruct and @PreDestroy
>> lifecycle callbacks may only declare interceptor binding types that are
>> defined as Target(TYPE). The PerformanceInterceptor declares
>> @PostConstruct callback and that's why the @Measure interceptor binding
>> has to defined as Target(TYPE).
>>
>> Martin
>>
>> Dne 11.6.2013 14:01, Radim Hanuš napsal(a):
>>> Hi,
>>>
>>> I just went through this thread and corresponding issue WELD-1416
>>> <https://issues.jboss.org/browse/WELD-1416> and still not clear for me
>>>
>>> Josef Hartinger referenced a statement from the current version of spec:
>>> "With the exception of AroundConstruct lifecycle callback interceptors,
>>> an interceptor for lifecycle callbacks may only declare interceptor
>>> binding types that are defined as Target(TYPE)."
>>>
>>> but does it mean that adding @AroundConstruct callback interceptor into
>>> class PerformanceInterceptor prevents from DefinitionException ?
>>> or in such case there should be only @AroundConstruct defined and none
>>> of both @PostConstruct and @PreDestroy ?
>>>
>>> enhanced sample of Jens Schumann:
>>>
>>> @Interceptor
>>> @Measure
>>> public class PerformanceInterceptor implements Serializable {
>>>
>>> @AroundInvoke
>>> public Object measure(InvocationContext ctx) throws Exception { ... }
>>>
>>> @PostConstruct
>>> public void measureCreate(InvocationContext ctx) { ... }
>>>
>>> *@AroundConstruct*
>>> Object onAroundConstruct(InvocationContext ctx) throws Exception {...}
>>> }
>>>
>>> @InterceptorBinding
>>> @Target({*ElementType.METHOD*, ElementType.TYPE})
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @Inherited
>>> public @interface Measure {
>>> }
>>>
>>>
>>> thanx for clarification,
>>> Radim
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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