As mentioned in the "JCDI Sandbox" discussion, one of the things that is part
of EJB that is not necessarily configurable is if a bean should be discarded if
a system exception is thrown. As of EJB 3.0 the @ApplicationException can flag
certain exceptions as not causing the bean to be discarded and the transaction
rolled back.
The problem with it though is annotating every possible exception is a leaky
approach. As well if the desire is simply to shut this behavior off for one
bean or method of a bean without affecting other beans/methods, there is no
solution.
So thinking to add support for counterpart to @ApplicationException that gets
closer to the real problem and simply lets users dictate how they want us to
handle system exceptions. Should we rollback as the spec says, should we
discard your bean as the spec says?
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.ElementType.METHOD;
import java.lang.annotation.Retention;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Target;
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface SystemException {
/**
* Should the bean instance be discarded
*/
boolean discard() default true;
/**
* Should the transaction rollback
*/
boolean rollback() default true;
/**
* Same as @ApplicationException
*/
boolean inherited() default true;
}
This would be applied to the bean itself or methods of a bean to dictate how
unchecked exceptions should be handled. As well it could be applied to
individual exceptions, like @ApplicationException, to turn even checked
exceptions into a SystemException. So a user could even use it to throw
checked exceptions and have them cause both rollback and instance removal.
What I imagine is that for @ManagedBean the default would be
SystemException(discard=false, rollback=false), and for all other bean types it
would be of course SystemException(discard=true, rollback=true)
Thoughts?
-David
