RE: [Springframework-developer] HTTP invoker remoting strategy

[Oliver H. <Ol...@ou...>]

> Regarding InterceptingRemoteInvocationExecutor: I'm not sure=20
> if such preInvocation and postInvocation hooks are really=20
> more convenient than directly overriding invoke.
> =20
> public class MyRemoteInvocationExecutor extends=20
> DefaultRemoteInvocationExecutor {
>   public Object invoke(RemoteInvocation invocation, Object=20
> targetObject)
>       throws NoSuchMethodException, IllegalAccessException,=20
> InvocationTargetException{
>    // do some pre-invocation handling
>    try {
>      super.invoke(invocation, targetObject);
>    }
>    finally {
>      // do some post-invocation handling
>    }
>  }
> }
>=20
> In particular, that variant allows to behave differently in=20
> case of a exception, etc: it's more flexible. Of course,=20
> preInvocation and postInvocation hooks still wouldn't hurt; I=20
> just don't feel that they add much value.
> =20
> Regarding retry support, this is definitely interesting=20
> functionality! We still need to nail down API details of such=20
> a RetryDecisionManager: For example, it might need=20
> information about the target service, regarding idempotent=20
> methods - similar to what WebLogic EJB offers:=20
> http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_reference
> .html#1026582.
> =20
> We could use declarative metadata for declaring methods as=20
> idempotent, or source-level attributes. In any case, the=20
> RetryDecisionManager has to have some information about the=20
> actual target service. As this potentially influences the=20
> RetryDecisionManager interface, I'd like to discuss this=20
> further before releasing it, that is, as a Spring 1.2=20
> feature. What do you think?
> =20

Retry with source-level attributes marking idempotent methods - very
nice. Though I was deliberately keeping the RetryDecisionManager
interface simple. When you start needing failover etc. perhaps it's time
to move to a more heavy weight server? Spring is certainly starting to
fatten up these days. (Probably because people like me keep pushing for
new features ;)