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<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 > > <ja...@carmanconsulting.com <javascript:;>> wrote: > > > On Sat, Jul 27, 2013 at 9:44 AM, Romain Manni-Bucau > > > <rmannibu...@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-unsubscr...@commons.apache.org<javascript:;> > > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > > > > >
