> 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
>
