commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [proxy] Refactoring Stub Support...
Date Sat, 27 Jul 2013 18:36:56 GMT
I do not plan on making us lose anything.  What I am looking for is to
build layers of abstraction.  The stuff you have developed right now I
would probably point at the lower-level abstractions that I'm writing
currently.  Does that make sense?

On Saturday, July 27, 2013, Matt Benson wrote:

> As I had mentioned, support for some form of dynamic response was the last
> feature I had wanted to get into the stub module, so I am certainly not
> opposed to this. I had simply thought to eat dog food by using [functor]
> interfaces, but that's not a big deal. I have not yet reviewed your latest
> work, but I really don't want to lose the fluent and typesafe API that
> exists currently.
>
> Matt
> On Jul 27, 2013 11:17 AM, "James Carman" <james@carmanconsulting.com<javascript:;>>
> wrote:
>
> > I have created
> >
> > https://issues.apache.org/jira/browse/PROXY-20
> >
> > to track the progress of this issue.  I have already checked in some
> > code into the branch.
> >
> >
> > On Sat, Jul 27, 2013 at 9:54 AM, James Carman
> > <james@carmanconsulting.com <javascript:;>> wrote:
> > > On Sat, Jul 27, 2013 at 9:44 AM, Romain Manni-Bucau
> > > <rmannibucau@gmail.com <javascript:;>> wrote:
> > >> Hi
> > >>
> > >> Isnt it a particular kind of interceptor/handler
> > (CompositeInterceptor)? So
> > >> does it need so much details?
> > >
> > > Well, the idea behind "stubbing" is that we would be specifying
> > > behavior for very specific method invocation cases (such as only a
> > > single method or only when the parameters match certain values).  If
> > > we introduce the abstractions I'm suggesting, we can handle these
> > > cases and many more.  I don't know if we need the Response concept,
> > > since the interface exactly matches the Interceptor interface.
> > > Perhaps we call the new class ConditionalInterceptor and you register
> > > InvocationMatcher/Interceptor pairs just so we don't have to re-invent
> > > the wheel.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>

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