Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 01/10/2012 02:14:16
PM:
> While we could adopt the EJB approach (modulo some renaming), Bill and
> I are concerned that it is too complex. (See Chapter 14 ("Exception
> Handling") of the EJB 3.1 spec for the gory details.)
>
> We propose a simpler approach along the following lines:
>
> By default, all exceptions should result in the current transaction
> being marked for rollback. If the developer believes that the
> exception should not cause rollback, he or she annotates the exception
> class with @DontRollbackTransaction (real name for this exception *TBD*).
>
> The DontRollbackTransaction annotation is simply:
>
> @Target(TYPE)
> @Retention(RUNTIME)
> @Inherited
> public @interface DontRollbackTransaction {}
In general, I'm ok with the simplified exception handling. I don't feel
particularly compelled to match the EJB exception model.
However, I do want to us to think about other implications. I think this
works perfectly fine for the local case. For remoting, do we expect MBs
to have an EJB, JAXWS, or REST component that sits in front of it and is
exception mapping now an application developer issue they have to worry
about?
I'm suspecting it always has been and this is nothing new, but I want to
make sure we're all ok with that.
Thanks,
Jim Knutson
WebSphere Java EE Architect