users@ejb-spec.java.net

[ejb-spec users] Re: [jsr345-experts] Re: [interceptors] @PostActivate, etc interceptor signature?

From: Mark Struberg <struberg_at_yahoo.de>
Date: Sat, 12 Jan 2013 09:05:53 +0000 (GMT)

> Let's try to avoid it, and reference Interceptors spec instead... Can
> you file a JIRA issue under the http://java.net/jira/browse/EJB_SPEC?


Yes, but for doing so we need this information in the interceptors spec first ;)


I've now created

http://java.net/jira/browse/INTERCEPTORS_SPEC-6


Hope that the intention is clear.

txs and LieGrue,
strub


----- Original Message -----
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: ejb-users <users_at_ejb-spec.java.net>
> Sent: Saturday, January 12, 2013 3:34 AM
> Subject: Re: [ejb-spec users] Re: [jsr345-experts] Re: [interceptors] @PostActivate, etc interceptor signature?
>
> On 1/11/13 5:54 PM, Mark Struberg wrote:
>>> This still leaves open Mark's (and my) question on how to specify
> the
>>> rules for those interceptors that are not explicitly defined in the
>>> interceptor spec.
>> The Interceptor method signature is one thing to define for those missing
> InterceptionTypes.
>> The
>>   second part which needs clarification is whether there is only one or
>> if the interceptors from the superclasses also get fired. Plus defining
>> the order of the invocations of course.
>
> Let's try to avoid it, and reference Interceptors spec instead... Can
> you file a JIRA issue under the http://java.net/jira/browse/EJB_SPEC?
>
> thanks,
> -marina
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>>> To: jsr345-experts_at_ejb-spec.java.net
>>> Cc:
>>> Sent: Saturday, January 12, 2013 2:08 AM
>>> Subject: [ejb-spec users] [jsr345-experts] Re: [interceptors]
> @PostActivate, etc interceptor signature?
>>>
>>> Welcome back David :)
>>>
>>> Good point (in particular because around-timeout method has the same
>>> signature as the around-invoke, while the method it interposes on is a
>>> void method that can't throw application exceptions).
>>>
>>> The interceptor spec is being updated as we speak (when Pete and I are
>>> happy with the changes and the layout, we'll send it for review).
> Please
>>> file an issue in the interceptors-spec JIRA:
>>> http://java.net/jira/browse/INTERCEPTORS_SPEC. Note that the change you
>>> propose will be an add-on, rather than a replacement for the current
>>> rules (for backward compatibility).
>>>
>>> This still leaves open Mark's (and my) question on how to specify
> the
>>> rules for those interceptors that are not explicitly defined in the
>>> interceptor spec.
>>>
>>> thanks,
>>> -marina
>>>
>>> On 1/9/13 10:08 AM, David Blevins wrote:
>>>>   Posted this yesterday, but not sure if it came through:
>>>>
>>>>   This is something I've been meaning to bring up.  Currently
> the rules
>>> are interceptor signatures for callbacks are not allowed to return
> Object or
>>> throw Exception.  Blogged about it here:
>>>
> http://blog.dblevins.com/2010/09/ejbnext-interceptor-improvements-method.html
>>>>   We chose that altered method signature because it effectively
> matched the
>>> method signature of the callback itself, but it has some terrible
> consequences.
>>> The worst is that InvocationContext.proceed() method signature is
> always the
>>> same:
>>>>       public Object proceed() throws Exception
>>>>
>>>>   When the Interceptor isn't allowed to have the same method
> signature it
>>> creates awkward and unfortunately unavoidable boiler plate:
>>>>       @PostConstruct
>>>>       @PreDestroy
>>>>       @PrePassivate
>>>>       @PostActivate
>>>>       @AroundTimeout
>>>>       public void callback(InvocationContext context) {
>>>>           try {
>>>>               intercept(context);
>>>>           } catch (Exception e) {
>>>>               if (e instanceof RuntimeException) {
>>>>                   throw (RuntimeException) e;
>>>>               } else{
>>>>                   throw new RuntimeException(e);
>>>>               }
>>>>           }
>>>>       }
>>>>
>>>>
>>>>   We should update the spec rules so that interceptor method
> signatures for
>>> callbacks are allowed to be the same and let the container handle the
> possible
>>> undeclared exception issues rather than force that upon the application
> code in
>>> every single callback interceptor they create.
>>>>
>>>>   -David
>>>>
>>>>   On Jan 8, 2013, at 1:45 PM, Marina Vatkina
>>> <marina.vatkina_at_oracle.com> wrote:
>>>>>   Good question. Looks like when Interceptors spec was created
> from the
>>> EJB spec, the PrePassivate/PostActivate callbacks were left in the EJB
> spec,
>>> while the rest was moved out.
>>>>>   We have (obviously) two choices:
>>>>>
>>>>>   1) add the method signatures (back) to the EJB spec section
> "7.5
>>> Interceptors for LifeCycle Event Callbacks"
>>>>>   2) change the Interceptors spec to distinguish between the LC
>>> interceptors in general and the ones that are supported (i.e.
>>> PostConstruct/PreDestroy).
>>>>>   WDYT?
>>>>>
>>>>>   thanks,
>>>>>   -marina
>>>>>
>>>>>   On 1/8/13 6:36 AM, Mark Struberg wrote:
>>>>>>   Hi folks!
>>>>>>
>>>>>>   The method signatures for @AroundInvoke and
> @PostConstruct
>>> _interceptors_ (not the postconstruct lifecycle methods, but the
> interceptors
>>> for them!) are well defined in the interceptors spec.
>>>>>>
>>>>>>
>>>>>>   But what about the method signatures for an interceptor
> for
>>> @PostActivate and the others which are defined in InterceptionType [1]?
>>>>>>   I didn't find anything about them in the interceptors
> spec.
>>> Where can I find this info?
>>>>>>
>>>>>>   txs and LieGrue,
>>>>>>   strub
>>>>>>
>>>>>>   [1]
>>>
> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/InterceptionType.html
>