David, you should now be able to set org.apache.webbeans.forceNoCheckedExceptions=false
somewhere in your openwebbeans.properties LieGrue, strub ----- Original Message ---- > From: Mark Struberg <[email protected]> > To: [email protected] > Sent: Thu, August 5, 2010 11:09:52 PM > Subject: Re: Interceptor callback signature strictness > > The rational behind the change is completely ok. > I would be happy if you could also bring this to the EE6/7 board, because > this > > is currently a real sick paradigma to only allow RuntimeExceptions > everywhere > (JPA lifecycle methods are another example) and to force wrapping the > wrapper >of > > an exceptionwrapper... until noone can see the real source of the problem > anymore... > > LieGrue, > strub > > > > ----- Original Message ---- > > From: David Blevins <[email protected]> > > To: [email protected] > > Sent: Thu, August 5, 2010 8:18:55 PM > > Subject: Interceptor callback signature strictness > > > > This is a debatable chance, but the goal is to somehow make it possible > > for > > >integrators to be less strict with this particular spec rule. > > > > http://svn.apache.org/viewvc?view=revision&revision=982715 > > > > Basically, we opted not to strictly enforce this as the > >invocationContext.proceed() method throws Exception so it forces all > >interceptors to needlessly catch and convert that checked exception to a > >runtime exception to meet the spec requirements: > > > > @PostConstruct > > public void construct(InvocationContext context) { > > try { > > context.proceed(); > > } catch (Exception e) { > > throw new RuntimeException(e); > > } > > } > > > > The result is that if a callback exception is thrown by the bean, it will >end > > >up being wrapped and re-thrown N number of times. > > > > Not terrible, but it is a bit of bad API. > > > > Anyway, if anyone sees a better way to do this I'm open to solutions. I >just > > >went with simple and direct so it would be easily revertible and > >changeable >if > > >we wanted to do something different. > > > > > > -David > > > > > > > >
