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

Mark Struberg struberg at yahoo.de
Thu Jun 20 04:19:45 EDT 2013


right, I was only looking at the old interceptors spec - my bad.

Now should we try to relax this restriction, or is there some good reason for it?


Liegrue,
strub




----- Original Message -----
> From: Marina Vatkina <marina.vatkina at oracle.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Jens Schumann <jens.schumann at openknowledge.de>; Martin Kouba <mkouba at redhat.com>; Radim Hanuš <radim.hanus at gmail.com>; "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 19 June 2013, 22:07
> Subject: Re: [cdi-dev] Lifecycle Callback Interceptor and @Target "METHOD"
> 
>T his is what it was in CDI 1.0:
> 
> "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."
> 
> So the restriction (however too strict) didn't change.
> 
> -marina
> 
> On 6/19/13 10:22 AM, Mark Struberg wrote:
>>  +1 for relaxing this restriction again to how it was before.
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Jens Schumann <jens.schumann at openknowledge.de>
>>>  To: Martin Kouba <mkouba at redhat.com>; Radim Hanuš 
> <radim.hanus at gmail.com>
>>>  Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>>>  Sent: Tuesday, 18 June 2013, 22:15
>>>  Subject: Re: [cdi-dev] Lifecycle Callback Interceptor and @Target 
> "METHOD"
>>> 
>>>  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
>>> 
>>  _______________________________________________
>>  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