> 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.
For legacy filters only implement onResponse, I think we can solve this by redirecting onError to onResponse by default. Jun > On Mar 4, 2019, at 11:53 AM, yuhang xiu <[email protected]> wrote: > > 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 >>> >>> >>
