Hello Pavel, I think your suggestion is better because it seems more flexible to me and only one method needs to be implemented by the user. So we don't need a default (no-op) implementation. But with this approach, a service can only have one interceptor, right? It also seems to be more error prone from the user side. The user may return a result of the wrong type for example. But I think this is ok, so if there is no objection, I will update the IEP and prepare a patch using the suggested approach.
вт, 28 июн. 2022 г. в 19:30, Pavel Tupitsyn <[email protected]>: > > Hello Pavel, > > The IEP looks good to me in general. It is a good addition to the service > API. > > One suggestion is to improve control over service method execution within > the interceptor: > 1. Bypass service call without throwing an exception. > 2. Convert service call result in some way > > This can be achieved by a different interface, with a single method: > > public interface ServiceCallInterceptor extends Serializable { > public default Object onInvoke(Supplier delegate, String mtd, Object[] > args, ServiceContext ctx) throws ServiceInterceptException { > return delegate.get(); > } > } > > which can be implemented like this: > > public class MyInterceptor implements ServiceCallInterceptor { > @Override > public Object onInvoke(Supplier delegate, String mtd, Object[] args, > ServiceContext ctx) throws Exception { > AuditProvider.get().recordStartEvent(mtd, > ctx.currentCallContext().attribute("sessionId")); > try { > if (!checkAuthorization(ctx)) > return notAuthorizedResult(); > > Object value = delegate.get(); > > return convert(value); > } > catch (Exception e) { > // Log error > return errorResult(...); > } > finally { > AuditProvider.get().recordEndEvent(mtd, > ctx.currentCallContext().attribute("sessionId")); > } > } > } > > > As you can see, this way the user has full control over all aspects of the > service call. > > Thoughts? > > On Tue, Jun 28, 2022 at 6:33 PM Pavel Pereslegin <[email protected]> wrote: > > > Hello Igniters! > > > > I want to continue discussing a feature that allows users to create > > their own middleware for Ignite services [1]. > > Earlier was added the ability to implicitly pass a set of user > > parameters (ServiceCallContext) to the service [2]. > > This feature allows users to track the origin of a service call. > > Now I'd like to add a service call interceptor to allow the user to > > separate the "middleware" logic from the business code and reduce > > boilerplate code [3]. > > > > I've prepared an IEP for this feature, please take a look [4]. > > I will prepare patches for Java and .NET for this feature soon. > > > > [1] https://lists.apache.org/thread/wqlvskxr0fvdo6rbo64bnct4zz53kpr0 > > [2] https://issues.apache.org/jira/browse/IGNITE-15572 > > [3] https://issues.apache.org/jira/browse/IGNITE-17022 > > [4] > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119 > >
