Hello,
I've updated IEP [1] and prepared a patch for Java services [2].
I'm going to merge it soon and continue working on the .NET service
interceptor [3].
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334119
[2] https://github.com/apache/ignite/pull/10128
[3]
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 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
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
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.
ср,
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
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
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