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