"ron.sigal(a)jboss.com" wrote : Is there any reason to prefer one solution over
the other? One could argue that an interruptible EJB or JMS client *should* declare that
it throws an InterruptedException, but that discussion might be more theological than
technical.
[theological] EJB business interface methods should not have to declare IE just because
the underlying library can be interrupted. You could use plain RMI that does not require
interface methods to declare InterruptedException but they do need to declare
RemoteException. Then again, plain RMI is neither performant and nor flexible, which is
why we created Remoting or Pooled Invoker...etc :)
"ron.sigal(a)jboss.com" wrote : I'm leaning towards wrapping in
RuntimeExceptions, which seems more straightforward and avoids the
UndeclaredThrowableException problem.
Sounds fine to me :).
"ron.sigal(a)jboss.com" wrote : There's one more concern. Suppose a Remoting
user detected the InterruptedException possibility and their code looks for
InterruptedExceptions wrapped in CannotConnectExceptions. Then replacing
CannotConnectExceptions with RuntimeExceptions might break their code. I'm leaning
towards
|
| 1. for Remoting 2.2.2.SP8
|
| a) leaving the current behavior in place as the default behavior, and
|
| b) making the new behavior a configurable alternative.
+1
"ron.sigal(a)jboss.com" wrote : 2. for Remoting 2.4.0, replacing the current
behavior with the new behavior.
|
| Now WDYT?
+1 as well.
I might a test on the AS side that replicates this and see how assert that the correct
thing is being thrown back to the client and whether the client can make further
invocations. I'd probably use some mocking for this.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146597#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...