We can rename "Supplier delegate" to "next", like in ASP.NET Core Middleware. So it is clear that there is a chain of calls.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/write?view=aspnetcore-6.0#middleware-class On Wed, Jun 29, 2022 at 2:08 PM Pavel Tupitsyn <ptupit...@apache.org> wrote: > > we can delegate interceptors as a chain > > Thanks Nikita, this was my thinking too. > > On Wed, Jun 29, 2022 at 1:55 PM Nikita Amelchev <namelc...@apache.org> > wrote: > >> Hello, >> >> The single method proposal looks good to me. >> >> > But with this approach, a service can only have one interceptor, right? >> >> Pavel, I think we can delegate interceptors as a chain. The last >> delegate calls the service method. In this way, multiple ordered >> interceptors can be configured. >> >> ср, 29 июн. 2022 г. в 12:13, Pavel Pereslegin <xxt...@gmail.com>: >> > >> > 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 <ptupit...@apache.org>: >> > > >> > > 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 <xxt...@gmail.com> >> 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 >> > > > >> >> >> >> -- >> Best wishes, >> Amelchev Nikita >> >
