Yep, thanks. ;-) On Jul 27, 2013 1:36 PM, "James Carman" <ja...@carmanconsulting.com> wrote:
> 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" <ja...@carmanconsulting.com> >> 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 >> > <ja...@carmanconsulting.com> wrote: >> > > On Sat, Jul 27, 2013 at 9:44 AM, Romain Manni-Bucau >> > > <rmannibu...@gmail.com> 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-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >
