Hi, About compatibility issues.
The current version will enter onResponse due to all requests (correct or incorrect). If we modify the code, the correct response enters onResponse, the error response enters onError, and onResponse will only process the correct request if the user does not modify the Filter code. Is this a problem that we should consider? Ian Luo <[email protected]> 于2019年3月3日周日 下午10:49写道： > Jun, > > In your new proposed interface, how could we construct a filter chain? Say, > how could filter-a process further a value processed by filter-b? > > Thanks, > -Ian. > > > On Fri, Mar 1, 2019 at 5:44 PM jun liu <[email protected]> wrote: > > > Hi, > > > > I am thinking of the possibility of changing the current Filter > definition > > model to make it totally asynchronous and event-driven. Here’s the > detailed > > proposal[1]. It’s only a immature idea at present so I am not sure fi > it’s > > good to have this change yet, especially from the user’s side. > > > > In short, the new Filter would look like: > > > > public interface Filter { > > void onSend(Invocation invocation) { > > // before invoke, throw exception to terminate > > } > > > > void onResponse(Result result, Invoker<?> invoker, Invocation > > invocation) { > > // biz return successfully > > } > > > > void onError(Throwable e) throws RpcException{ > > // biz throw exception > > } > > } > > > > 1. https://github.com/apache/incubator-dubbo/issues/3585 > > > > Jun > > > > >
