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" <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
