commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [proxy] Refactoring Stub Support...
Date Sat, 27 Jul 2013 13:44:38 GMT
Hi

Isnt it a particular kind of interceptor/handler (CompositeInterceptor)? So
does it need so much details?
Le 27 juil. 2013 15:31, "James Carman" <jcarman@carmanconsulting.com> a
écrit :

> I think we need to re-think the stubbing support in proxy2.  I'm not
> saying I don't like the idea.  What I propose is that we introduce some
> lower-level abstractions on which the stubbing is built.  For instance, I
> would propose we introduce a couple of interfaces (or the concept of these
> interfaces):
>
> public interface InvocationMatcher {
>   boolean matches(Invocation invocation);
> }
>
> public interface Response {
>   Object response(Invocation invocation);
> }
>
> Using these two simple interfaces, we could support all sorts of
> "filtered" interceptors.  For stubbing, I could imagine an interceptor like
> this:
>
> public class AdviceInterceptor implements Interceptor {
>   private final List<Advice> advices = …;
>
>   public void advise(InvocationMatcher matcher, Response response) {
>     advices.add(new Advice(matcher, response));
>   }
>
>   Object intercept( Invocation invocation ) throws Throwable {
>     for(Advice advice: advices) {
>       if(advice.getMatcher().matches(invocation)) {
>         return advice.getResponse().respond(invocation);
>       }
>     }
>     return invocation.proceed();
>   }
>
>   private class Advice {
>     private final InvocationMatcher matcher;
>     private final Response response;
>     ...
>   }
> }
>
> All of the stubbing support could be built upon these simple concepts and
> then it would also be available to our users to invent their own ingenious
> ways to do interception.  What do you think?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message