An application exception shall be thrown when there is a business-logic error, as opposed to a system error.
There is an important difference: application exceptions do not automatically cause a transaction to rollback. The client has an opportunity to recover after an application exception is thrown.
Application exceptions are sent to the client without being repackaged as an EJBException. Therefore, you can use them to report validation errors or business logic problems, and they will reach the client.
Does this include all exceptions, runtime and checked regardless the
source?
No. By default, application exceptions are the exceptions that do not extend RuntimeException or RemoteException. You can change this, as described below.
How can I influence the behaviour by using the ApplicationException
annotation?
You can use @ApplicationException(rollback=true) if you want the transaction to be rolled back automatically.
You can also use the annotation on subclasses of RuntimeException and RemoteException, in order to avoid wrapping as EJBExceptions, and define their automatic rollback behavior.
What about exceptions thrown by other Java EE libraries?
They will follow the same rules, but you can use the XML descriptor to declare third party classes as application exceptions (with or without automatic rollback).
What about other exceptions thrown by provider code?
Not sure, I think you'd rarely see a non system error (Remote or Runtime exceptions) coming from provider code.
Does it make a difference if the exception is wrapped in an EJBException?
Yes. It will impact how you handle exceptions in the client code.
(Ref: Enterprise JavaBeans 3.0, Bill Burke, O'Reilly)
I hope it helps a bit.
