Re: [Springframework-developer] HTTP invoker remoting strategy

[<jue...@we...>]

Hi Ollie,
=20
Regarding InterceptingRemoteInvocationExecutor: I'm not sure if such =
preInvocation and postInvocation hooks are really more convenient than =
directly overriding invoke.
=20
public class MyRemoteInvocationExecutor extends =
DefaultRemoteInvocationExecutor {
  public Object invoke(RemoteInvocation invocation, Object targetObject)
      throws NoSuchMethodException, IllegalAccessException, =
InvocationTargetException{
   // do some pre-invocation handling
   try {
     super.invoke(invocation, targetObject);
   }
   finally {
     // do some post-invocation handling
   }
 }
}

In particular, that variant allows to behave differently in case of a =
exception, etc: it's more flexible. Of course, preInvocation and =
postInvocation hooks still wouldn't hurt; I just don't feel that they =
add much value.
=20
Regarding retry support, this is definitely interesting functionality! =
We still need to nail down API details of such a RetryDecisionManager: =
For example, it might need information about the target service, =
regarding idempotent methods - similar to what WebLogic EJB offers: =
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_reference.html#10265=
82.
=20
We could use declarative metadata for declaring methods as idempotent, =
or source-level attributes. In any case, the RetryDecisionManager has to =
have some information about the actual target service. As this =
potentially influences the RetryDecisionManager interface, I'd like to =
discuss this further before releasing it, that is, as a Spring 1.2 =
feature. What do you think?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Oliver Hutchison
Gesendet: Mo 16.08.2004 06:39
An: spr...@li...
Betreff: RE: [Springframework-developer] HTTP invoker remoting strategy



Andy, J=FCrgen,

I've been away for the last week so sorry for the late reply.

Attached are some files that add retry support to all the standard =
Spring remoting methods. The support is not as complete as my own =
remoting implementation but for most cases should work fine. There's =
also some code to allow metadata to be attached to RemoteInvocations (I =
think this stuff only works for the RMI and HTTP remoting).

J=FCrgen would you consider adding this code? The retry support could =
integrated higher up the class hierarchy perhaps as a subclass of =
RemoteAccessor?

Following is an example config.

Client:
    <bean id=3D"theManager" =
class=3D"org.springframework.remoting.support.RertyingClientProxyFactoryB=
ean">
        <property name=3D"wrapedRemoteAccessor"><ref =
local=3D"theManagerTarget" /></property>
        <property name=3D"retryDecisionManager"><ref =
local=3D"retryDecisionManager" /></property>      =20
    </bean>

    <bean id=3D"theManagerTarget" =
class=3D"org.springframework.remoting.httpinvoker.HttpInvokerClientInterc=
eptor">
        <property =
name=3D"serviceInterface"><value>ourcommunity.TheManager</value></propert=
y>
        <property =
name=3D"serviceUrl"><value>https://${oc.server.addr}/ra/theManager</value=
></property>
        <property name=3D"remoteInvocationFactory"><ref =
local=3D"remoteInvocationFactory" /></property>
    </bean>
  =20
    <bean id=3D"remoteInvocationFactory" =
class=3D"ourcommunity.admin.util.remoting.SecurityRemoteInvocationFactory=
" />

    <bean id=3D"retryDecisionManager" =
class=3D"ourcommunity.admin.util.remoting.OCRetryDecisionManager" />

Server:

    <bean id=3D"remoteInvocationExecutor" =
class=3D"ourcommunity.util.remoting.SecureRemoteInvocationExecutor" />
  =20
    <bean name=3D"/ra/theManager" =
class=3D"org.springframework.remoting.httpinvoker.HttpInvokerServiceExpor=
ter">
        <property =
name=3D"serviceInterface"><value>ourcommunity.TheManager</value></propert=
y>
        <property name=3D"service"><bean =
class=3D"ourcommunity.TheManagerImpl" /></property>      =20
        <property name=3D"remoteInvocationExecutor"><ref =
bean=3D"remoteInvocationExecutor" /></property>
    </bean>