It's pretty easy. lifecycle interceptors signature doesnt have any throws Exception. But InvocationContext.proceed() does!
Thus you always need some nasty glue code:
@PostConstruct
public void atCreationTime(InvocationContext ic)
{
try
{
ic.proceed();
}
catch (Exception e)
{
ExceptionUtil.throwAsRuntimeException(e);
}
}
LieGrue,
strub
----- Original Message -----
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: "users_at_ejb-spec.java.net" <users_at_ejb-spec.java.net>
> Sent: Tuesday, January 15, 2013 2:05 AM
> Subject: Re: [ejb-spec users] Re: [jsr345-experts] [interceptors] @PostActivate, etc interceptor signature?
>
> I'm not sure I understand your concerns here....
>
> -marina
>
> On 1/12/13 5:21 AM, Mark Struberg wrote:
>> I found another thing we must consider.
>>
>> @PostConstruct methods must not throw a checked Exception.
>> The problem would happen with EJB style interceptors which do not denote
> anything on the interceptor class itself. Another case is when you have a parent
> interceptor..
>>
>> having some
>>
>> public class InterceptorParent {
>>
>> @PostConstruct
>> public void init(InvocationContext ic) throws Exception {
>> ic.proceed();
>> }
>> }
>>
>> would currently complain that a @PostConstruct method must not throw a
> checked Exception.
>> We should relax that case to not apply for methods with an
> InvocationContext parameter type.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>
>>> ________________________________
>>> From: David Blevins <david.blevins_at_gmail.com>
>>> To: marina.vatkina_at_oracle.com
>>> Cc: Mark Struberg <struberg_at_yahoo.de>; ejb-users
> <users_at_ejb-spec.java.net>; jsr345-experts_at_ejb-spec.java.net
>>> Sent: Wednesday, January 9, 2013 7:08 PM
>>> Subject: [ejb-spec users] Re: [jsr345-experts] [interceptors]
> @PostActivate, etc interceptor signature?
>>>
>>> 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
>>>>>
>>>
>>>
>>>
>