EJBs, RuntimeExceptions, Proxies, etc.

[dortman]

Hi,

We have some client code which is calling some objects which we have decided to deploy into a container. So we impelemnted the EJB using LocalStatelessSessionProxyFactoryBean, used SimpleRemoteStatelessSessionProxyFactoryBean to access it, and all is well.

However, some of our business methods throw unchecked exceptions. This is causing issues, as the EJB spec states that these are to be classified as SystemExceptions, and require that the bean be discarded. We would like to avoid this for obvious reasons.

However, we're unsure that we want to convert the exceptions to checked exceptions. Which brings us to my question.

What is the inherent wisdom (either negative or positive) of casting our RuntimeExceptions to CheckedExceptions in the EJB class (either in the wrapper methods, or via proxy), and then placing an AOP aspect on the client side EJB proxy to wrap our temporary checked exception back into the original RuntimeException? Has anybody been this creative before?

We my look at our checked vs. unchecked assumptions first, to see if our concern is moot. But it would be nice to know what path others have taken.

Thanks,
-Dave

[wpoitras]

If you wrap your unchecked exceptions in EJBExceptions, a remote call will throw a RemoteException. If your Spring proxy uses an interface that doesn't throw RemoteException, then the proxy will wrap those exceptions in RemoteAccessException.

[dortman]

If you wrap your unchecked exceptions in EJBExceptions, a remote call will throw a RemoteException. If your Spring proxy uses an interface that doesn't throw RemoteException, then the proxy will wrap those exceptions in RemoteAccessException.

I'm still not sure how everything is going to come together, but if that's the case, we could use a Throws Advice to fetch the original exception from within the RemoteAcessException and toss it:

http://www.springframework.org/docs/...p.html#d0e4068

Thus making the calling code completely unaware of what's going on when it makes a call to the interface.

Again, I'm not sure if we're not trying to get too creative. But *IF* tossing unchecked exceptions from an EJB makes sense, would it be a poor decision to accomplish that through this sort of approach?

-Dave

[Andreas Senft]

I would refrain from throwing unchecked exceptions from EJBs (and also wrapping it into an EJB exception).
As already stated, runtime exceptions are interpreted as system exceptions by the container and further the offending been will be unloaded from the bean pool. Since this might cause severe performance degradations I would be careful here. You might end up with the container creating a new EJB instance for each method call that fails.

Regards,
Andreas