EJBException vs. RemoteException

[redijedi]

It seems as though EJB3 has gotten rid of RemoteExceptions and simply replaced them with EJBExceptions. I do not see how this is an improvement. Other than the fact that the EJBExceptions are RuntimeExceptions, there is no improvement as I see it. Every single Exception I throw from my EJB is wrapped in an EJBException. Therefore, in my client code I still have to be aware of the underlying implementation just as I did with RemoteExceptions. Then I have to use the getCausedByException and do instanceof until my code is a mess of if statements.

As an interim solution I've got Spring AOP intercepting thrown Exceptions, and turning them back into the original Exception. This works, but it's a hack I've been forced into.

Has anyone else run into this annoyance, or am I doing something wrong?

[bill.burke]

This isn't entirely true:

Only raw RuntimeExceptions should be wrapped in EJBException. Checked exceptions won't be. Checked or Unchecked exceptions annotated with @ApplicationException won't be either. If they are, it is a bug in our impl. In certain transactional situations, things are wrapped in a EJBTransactionRolledBackException, but this is to inform the client that a rollback occured.

Also, the proposed final just added a <application-exception> element to the ejb-jar.xml deployment descriptor. This is a way to specify that third-party. We don't support it yet though.

Don't know if this helps or not. let me know

[redijedi]

This does help. I will use the annotation specified. Thank you.

[redijedi]

Can you prevent EJBTransactionRolledBackException from being returned to the client? I do not wish the client to know if a rollback has occurred in certain situations.