Pavel,
> From my point of view, this should not break anything
Removing parameters from a public interface method is a breaking change,
or do you mean something else?
Regarding .NET - let's have a separate ticket for that?
We can discuss and implement Java changes first.
On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin <xxt...@gmail.com> wrote:
> Thanks a lot for your suggestions.
>
> > We might consider injecting the ServiceContext instead of passing it to
> > IgniteService methods, but I believe this will be a breaking change?
>
> From my point of view, this should not break anything. We can inject a
> service context when initializing a service and keep it accessible in
> state transition methods (init/execute/cancel).
> Currently, in .Net ServiceContext doesn't share the same instance, but
> this can be reworked - for example, we can store the service context
> (with a reference to the service) in the resource registry instead of
> the service itself.
>
> But I don't see much usability improvement with such a feature if the
> user still needs to implement state transition methods. I think it
> would be nice to add default "no-op" implementations for them.
> Unfortunately, we are currently unable to do the same in .Net because
> such a feature is not supported in C# 4.0 (it's available in C# 8.0).
>
> Can we add default "no-op" implementations for init/execute/cancel
> methods in Java and leave them unchanged in .Net?
>
> вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko
> <valentin.kuliche...@gmail.com>:
> >
> > I support #2, because we already have the ServiceContext. Having
> > both ServiceContext and @ServiceRequestContextResource that injects some
> > function (or any other mechanism for that matter) will be VERY confusing.
> > Let's keep it simple.
> >
> > At the same time, I do agree with Nikolay that injection is the approach
> > taken across the platform, so I'm not sure why we are not using it here.
> We
> > might consider injecting the ServiceContext instead of passing it to
> > IgniteService methods, but I believe this will be a breaking change?
> >
> > -Val
> >
> > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky <ivanda...@gmail.com>
> wrote:
> >
> > > I am for limiting types of attributes values only to UTF-8 strings and
> > > bytearrays.
> > > Also, I agree with Pavel, (2) is clear and without any reflection.
> > >
> > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov <nizhi...@apache.org>:
> > >
> > > > I like (1) options.
> > > >
> > > > @ServiceRequestContextResource
> > > > private Function<String, Object> ctxFunc;
> > > >
> > > > Because, we use this style of API for injection of other resources -
> > > > logger, ignite instance, etc.
> > > > It may be confusing for the user to use several API styles for
> solving
> > > > similar tasks.
> > > >
> > > >
> > > > > 19 окт. 2021 г., в 11:04, Pavel Tupitsyn <ptupit...@apache.org>
> > > > написал(а):
> > > > >
> > > > > (2) seems to be the cleanest and most discoverable to me,
> > > > > also simpler to implement (no reflection necessary).
> > > > >
> > > > > But existing ServiceContext properties are for the entire
> instance, not
> > > > for
> > > > > the current call.
> > > > > So, to make it clear and obvious, let's do
> > > > > ServiceContext.currentCallContext().attribute(...).
> > > > >
> > > > > On Mon, Oct 18, 2021 at 7:20 PM Pavel Pereslegin <xxt...@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> Folks,
> > > > >>
> > > > >> I agree with Ivan that we can improve the user experience in
> Ignite
> > > > >> services by adding support for "middleware".
> > > > >> And as a first step, we need to pass the "caller context" to the
> > > > service.
> > > > >>
> > > > >> I see the following API options for reading this "context" inside
> a
> > > > >> service:
> > > > >> (please see "API proposal" section in Jira [1] for full formatted
> > > > examples)
> > > > >>
> > > > >> 1. Using a custom annotation (ServiceRequestContextResource) and
> > > > >> reading context attributes with a function.
> > > > >>
> > > > >> @ServiceRequestContextResource
> > > > >> private Function<String, Object> ctxFunc;
> > > > >>
> > > > >> public void serviceMethod() {
> > > > >> String login = (String)ctxFunc.apply("login");
> > > > >> }
> > > > >>
> > > > >> 2. Using a new method of the existing ServiceContext.
> > > > >>
> > > > >> private ServiceContext svcCtx;
> > > > >>
> > > > >> public void init(ServiceContext svcCtx) {
> > > > >> this.svcCtx = svcCtx;
> > > > >> }
> > > > >>
> > > > >> public void serviceMethod() {
> > > > >> String login = svcCtx.attribute("login");
> > > > >> // and/or
> > > > >> String login = (String)svcCtx.attributes().get("login");
> > > > >> }
> > > > >>
> > > > >>
> > > > >> The next two options require wrapping Map<String, Object> into a
> new
> > > > >> ServiceRequestContext class.
> > > > >>
> > > > >> 3. Read context "wrapper" using special annotation and supplier.
> > > > >>
> > > > >> @ServiceRequestContextResource
> > > > >> private Supplier<ServiceRequestContext> ctxSupplier;
> > > > >>
> > > > >> public void serviceMethod() {
> > > > >> String login = ctxSupplier.get().attribute("login");
> > > > >> }
> > > > >>
> > > > >> 4. Using the special static method of the "wrapper" class.
> > > > >>
> > > > >> public void serviceMethod() {
> > > > >> String login =
> > > > ServiceRequestContext.current().attribute("login");
> > > > >> }
> > > > >>
> > > > >> Let's discuss which one is the way to go.
> > > > >>
> > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-15572
> > > > >>
> > > > >> вт, 12 окт. 2021 г. в 13:51, Ivan Daschinsky <ivanda...@gmail.com
> >:
> > > > >>>
> > > > >>> Hi, Val
> > > > >>>
> > > > >>>>> The examples you mentioned are more related to internal
> activities
> > > > >> (e.g.,
> > > > >>>>> if authentication is handled by an Ignite server node, it can
> > > create
> > > > >> its
> > > > >>>>> internal context for a connection - this is certainly
> reasonable).
> > > > I'm
> > > > >>> only
> > > > >>>>> worried about exposing this to the end user.
> > > > >>>
> > > > >>> I'm talking about not Ignite auth, but external auth. Here I am
> > > > >> considering
> > > > >>> Ignite Service Grid as a microservice platform.
> > > > >>> Authentication microservice can be not related to Ignite at all,
> but
> > > > >> author
> > > > >>> of service may want to retrieve or authenticate user by user_id,
> that
> > > > is
> > > > >>> provided in request headers or context in jwt token, for example.
> > > > >>>
> > > > >>> The same is for tracing or metrics. Ignite internal mechanisms
> here
> > > > >> cannot
> > > > >>> help at all, because there is no context related to user's code.
> > > > >>>
> > > > >>> If we want to leave Ignite Service Grid as dump as possible, it
> is
> > > ok.
> > > > >> But
> > > > >>> therefore it cannot compete with more functional variants.
> > > > >>>
> > > > >>> But just adding request headers at first step and custom
> interceptors
> > > > >>> (client and server side) we can give to user's of Ignite Service
> > > Grid
> > > > a
> > > > >>> lot of opportunities.
> > > > >>>
> > > > >>> There is an example of golang grpc middlewares -- see how many
> > > > >> interesting
> > > > >>> use cases here:
> > > > >>> https://github.com/grpc-ecosystem/go-grpc-middleware
> > > > >>>
> > > > >>> вт, 12 окт. 2021 г. в 07:31, Valentin Kulichenko <
> > > > >>> valentin.kuliche...@gmail.com>:
> > > > >>>
> > > > >>>> Ivan,
> > > > >>>>
> > > > >>>> I'm a bit confused :) Unless I misread the initial suggestion,
> the
> > > > >> idea is
> > > > >>>> to provide a public API to create the context. In other words,
> it
> > > will
> > > > >> be
> > > > >>>> up to the end user to create this context properly, which
> affects
> > > the
> > > > >>>> business code - and that's exactly where I see an issue.
> > > > >>>>
> > > > >>>> The examples you mentioned are more related to internal
> activities
> > > > >> (e.g.,
> > > > >>>> if authentication is handled by an Ignite server node, it can
> create
> > > > >> its
> > > > >>>> internal context for a connection - this is certainly
> reasonable).
> > > I'm
> > > > >> only
> > > > >>>> worried about exposing this to the end user.
> > > > >>>>
> > > > >>>> Maybe you can pick one of the use cases that you think would
> benefit
> > > > >> from
> > > > >>>> this feature the most, and provide a little more detail? How
> would
> > > you
> > > > >> like
> > > > >>>> to see the use case to be addressed and what is currently
> missing?
> > > > >>>>
> > > > >>>> Also, just to be clear: I'm not necessarily against the
> suggestion,
> > > > and
> > > > >>>> it's highly unlikely that I will want to veto it if you or
> someone
> > > > else
> > > > >>>> will decide to implement it. Just expressing my concerns.
> > > > >>>>
> > > > >>>> -Val
> > > > >>>>
> > > > >>>> On Sun, Oct 10, 2021 at 11:52 PM Nikolay Izhikov <
> > > nizhi...@apache.org
> > > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> +1 to have service proxy context.
> > > > >>>>>
> > > > >>>>>> 11 окт. 2021 г., в 09:43, Ivan Daschinsky <
> ivanda...@gmail.com>
> > > > >>>>> написал(а):
> > > > >>>>>>
> > > > >>>>>> Val, Pavel both of you are right, but on the other hand there
> are
> > > > >> some
> > > > >>>>>> other tasks
> > > > >>>>>>
> > > > >>>>>> 1. Distributed tracing.
> > > > >>>>>> 2. Custom metrics/measurements
> > > > >>>>>> 3. Auth and some related tasks (i.e. ingests full User info by
> > > > >> calling
> > > > >>>>> some
> > > > >>>>>> auth service in middleware).
> > > > >>>>>>
> > > > >>>>>> Do you both think that this is a good idea in business code?
> > > > >>>>>>
> > > > >>>>>> Without this functionality, our service grid cannot compete
> with
> > > > >> grpc
> > > > >>>> and
> > > > >>>>>> others as microservice framework, unfortunately.
> > > > >>>>>>
> > > > >>>>>> But if we introduce limited support for this "request
> headers", it
> > > > >> can
> > > > >>>>>> drastically improves this aspects of our service grid
> framework.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> пн, 11 окт. 2021 г. в 00:48, Valentin Kulichenko <
> > > > >>>>>> valentin.kuliche...@gmail.com>:
> > > > >>>>>>
> > > > >>>>>>> I agree with Pavel. The suggested approach is indeed utilized
> > > > >> quite
> > > > >>>>>>> frequently, but it's inherently error-prone.
> > > > >>>>>>>
> > > > >>>>>>> The main issue is that it creates implicit assumptions about
> the
> > > > >>>>> behavior
> > > > >>>>>>> of both the service and the user's code. For example, if the
> > > > >> user's
> > > > >>>> code
> > > > >>>>>>> must provide a username, what if it doesn't? I assume it
> will get
> > > > >> an
> > > > >>>>> error,
> > > > >>>>>>> which is very counterintuitive. Even more importantly, how
> should
> > > > >> one
> > > > >>>>> learn
> > > > >>>>>>> about this requirement in the first place? It is not
> reflected in
> > > > >> the
> > > > >>>>> API
> > > > >>>>>>> in any way - and that's a big problem.
> > > > >>>>>>>
> > > > >>>>>>> The fact that the service implementor needs to update the API
> > > > >> methods
> > > > >>>>> when
> > > > >>>>>>> such requirements are introduced is actually a good thing,
> in my
> > > > >>>>> opinion.
> > > > >>>>>>> This forces the developer to stop and think about how the
> updated
> > > > >> API
> > > > >>>>>>> should look like and how to make sure it's
> backward-compatible
> > > (or
> > > > >>>> not,
> > > > >>>>> in
> > > > >>>>>>> case the new requirements are mandatory). Doing this through
> an
> > > > >>>> external
> > > > >>>>>>> context is basically the equivalent of saying "let the end
> user
> > > > >> deal
> > > > >>>>> with
> > > > >>>>>>> this". Not a good practice, in my view.
> > > > >>>>>>>
> > > > >>>>>>> Conversely, passing everything exclusively via method
> arguments
> > > > >>>>> guarantees
> > > > >>>>>>> that:
> > > > >>>>>>>
> > > > >>>>>>> - The user's code is always compliant with the service
> > > > >> contract. You
> > > > >>>>>>> can't "forget" to pass something to the service.
> > > > >>>>>>> - Any changes in the service contract (backward-compatible
> or
> > > > >>>>> otherwise)
> > > > >>>>>>> are explicitly reflected in the API.
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> -Val
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On Sun, Oct 10, 2021 at 6:21 AM Pavel Tupitsyn <
> > > > >> ptupit...@apache.org>
> > > > >>>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Ivan,
> > > > >>>>>>>>
> > > > >>>>>>>> Yes, this approach is used by some other systems, and
> still, I
> > > > >> don't
> > > > >>>>> like
> > > > >>>>>>>> it very much.
> > > > >>>>>>>> Let's hear more opinions.
> > > > >>>>>>>>
> > > > >>>>>>>> On Sat, Oct 9, 2021 at 9:00 PM Ivan Daschinsky <
> > > > >> ivanda...@gmail.com>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> Hi.
> > > > >>>>>>>>> Pavel T., Ok, http rest dosn't have the clean design, in
> your
> > > > >>>> opinion.
> > > > >>>>>>>>>
> > > > >>>>>>>>> But what about grpc? The same?
> > > > >>>>>>>>>
> > > > >>>>>>>>> As for me, it is ok to pass additional parameters as list
> of
> > > > >>>> key-value
> > > > >>>>>>>>> pairs with keys as strings and values as bytearrays or
> strings.
> > > > >> It
> > > > >>>> is
> > > > >>>>>>> ok
> > > > >>>>>>>> to
> > > > >>>>>>>>> allow user to set up middlewares for services and allow to
> > > > >> enrich
> > > > >>>>>>> request
> > > > >>>>>>>>> context in this middlewares. It is very common approach
> > > > >> everywhere
> > > > >>>> and
> > > > >>>>>>> is
> > > > >>>>>>>>> very useful in distributed systems. The use cases are so
> > > > >> obvious,
> > > > >>>>>>> aren't
> > > > >>>>>>>>> they?
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> сб, 9 окт. 2021 г., 20:14 Pavel Tupitsyn <
> ptupit...@apache.org
> > > > >>> :
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Pavel,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Thanks for the explanation, I understand the use cases.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> in REST service, he can set such parameters in request
> > > headers
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I don't consider HTTP-based services as a good example of
> a
> > > > >>>>>>>>>> clean architecture.
> > > > >>>>>>>>>> Data can be passed in URL parameters, in headers, and in
> body,
> > > > >> and
> > > > >>>>>>> each
> > > > >>>>>>>>> of
> > > > >>>>>>>>>> those ways has its own limitations.
> > > > >>>>>>>>>> There is no obvious correct way to do things.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>>> Ambient state is not obvious and the API looks confusing
> > > even
> > > > >>>>>>>> though I
> > > > >>>>>>>>>> understand our services stack quite well both in Java and
> .NET
> > > > >>>>>>>>>>> Can you clarify please?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> The proposed API adds a "side channel" for the data.
> > > > >>>>>>>>>> Some is passed as arguments, which is obvious, and some
> > > becomes
> > > > >>>>>>>> magically
> > > > >>>>>>>>>> available on the server side through some external
> context.
> > > > >>>>>>>>>> - You have to know about the context
> > > > >>>>>>>>>> - You have to understand that the context is only
> available
> > > > >> during
> > > > >>>>>>> the
> > > > >>>>>>>>>> method call (can't use it in some background logic)
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> In my opinion, this is a bit too clever. I'm a fan of the
> > > > >>>> functional
> > > > >>>>>>>>>> programming approach where everything you need is passed
> as
> > > > >>>>>>> arguments.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Fri, Oct 8, 2021 at 4:29 PM Pavel Pereslegin <
> > > > >> xxt...@gmail.com>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> Igor, Pavel.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Why can not a user implement such context on application
> > > > >> level? I
> > > > >>>>>>>>>>> believe Ignite provides all necessary tools for that.
> > > > >>>>>>>>>>> The user wants to trace the source of the service call.
> For
> > > > >>>>>>> example,
> > > > >>>>>>>> a
> > > > >>>>>>>>>>> service must log the name of the user who made the calls
> of
> > > > >> the
> > > > >>>>>>>>>>> service. For now, there's no possibility to do that
> without
> > > > >>>>>>> modifying
> > > > >>>>>>>>>>> the service interface and implementation. Moreover, the
> user
> > > > >> must
> > > > >>>>>>>>>>> modify all methods of service to pass this parameter. For
> > > > >> example,
> > > > >>>>>>> in
> > > > >>>>>>>>>>> REST service, he can set such parameters in request
> headers,
> > > > >> why
> > > > >>>> we
> > > > >>>>>>>>>>> can't provide such usability in Ignite.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> This will reduce the performance of all calls
> > > > >>>>>>>>>>> This feature is optional, if the context is not passed -
> then
> > > > >>>>>>> there's
> > > > >>>>>>>>>>> shouldn't be any performance difference.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Ambient state is not obvious and the API looks confusing
> > > even
> > > > >>>>>>>> though
> > > > >>>>>>>>> I
> > > > >>>>>>>>>>> understand our services stack quite well both in Java and
> > > .NET
> > > > >>>>>>>>>>> Can you clarify please?
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> пт, 8 окт. 2021 г. в 15:46, Pavel Tupitsyn <
> > > > >> ptupit...@apache.org
> > > > >>>>> :
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Agree with Igor.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I'm not sure this feature is a good fit for Ignite.
> > > > >>>>>>>>>>>> Ignite should not be responsible for such a high-level
> > > > >> concept,
> > > > >>>>>>>> this
> > > > >>>>>>>>>>> should
> > > > >>>>>>>>>>>> be on the application side instead.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> - As Eduard noted, it is hard to make this type-safe
> > > > >>>>>>>>>>>> - Ambient state is not obvious and the API looks
> confusing
> > > > >> even
> > > > >>>>>>>>> though
> > > > >>>>>>>>>> I
> > > > >>>>>>>>>>>> understand our services stack quite well both in Java
> and
> > > > >> .NET
> > > > >>>>>>>>>>>> - This will reduce the performance of all calls
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Fri, Oct 8, 2021 at 3:44 PM Igor Sapego <
> > > > >> isap...@apache.org>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Hi guys,
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Why can not a user implement such context on
> application
> > > > >> level?
> > > > >>>>>>>>>>>>> I believe Ignite provides all necessary tools for that.
> > > User
> > > > >>>>>>> can
> > > > >>>>>>>>> just
> > > > >>>>>>>>>>>>> implement such a context as user type and pass it to
> > > > >> services
> > > > >>>>>>>> they
> > > > >>>>>>>>>>>>> need. Are the arguments why would Ignite need a
> separate
> > > > >>>>>>> feature
> > > > >>>>>>>>>>>>> for such a use case?
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Best Regards,
> > > > >>>>>>>>>>>>> Igor
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Fri, Oct 8, 2021 at 2:17 PM Eduard Rakhmankulov <
> > > > >>>>>>>>>>> erixon...@gmail.com>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> I am not aware .NET capabilities, but as I can see
> service
> > > > >>>>>>> must
> > > > >>>>>>>>> be
> > > > >>>>>>>>>>>>>> implemented in *java* and even if can't serialize
> other
> > > > >> that
> > > > >>>>>>>> Map
> > > > >>>>>>>>> on
> > > > >>>>>>>>>>> .NET
> > > > >>>>>>>>>>>>>> side, on java side we can wrap this map with provided
> > > > >>>>>>>>> TypedContext
> > > > >>>>>>>>>>>>> (context
> > > > >>>>>>>>>>>>>> should be convertible from map in this case).
> > > > >>>>>>>>>>>>>> That leads to a situation when Java can use
> TypedContext
> > > > >> but
> > > > >>>>>>>>> other
> > > > >>>>>>>>>>>>> clients
> > > > >>>>>>>>>>>>>> can't. I believe that the majority of services users
> are
> > > > >>>>>>> using
> > > > >>>>>>>>> Java
> > > > >>>>>>>>>>> and
> > > > >>>>>>>>>>>>> it
> > > > >>>>>>>>>>>>>> should be taken in accordance.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> P.S. I think it is possible to send plain objects from
> > > .NET
> > > > >>>>>>>>> context
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>>> cluster.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Best regards, Ed
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin <
> > > > >>>>>>>> xxt...@gmail.com>
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Hi, Eduard!
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Thanks for your feedback.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> The idea sounds very good, but don't forget about the
> > > > >>>>>>>> platform
> > > > >>>>>>>>>>>>> services.
> > > > >>>>>>>>>>>>>>> For example, we may call Java service from .Net and
> > > > >>>>>>>> vice-versa.
> > > > >>>>>>>>>> I'm
> > > > >>>>>>>>>>>>>>> not sure if the context can be implemented as a
> custom
> > > > >>>>>>> class
> > > > >>>>>>>>>>> (instead
> > > > >>>>>>>>>>>>>>> of Map/Dictionary) in this case.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> пт, 8 окт. 2021 г. в 14:21, Eduard Rakhmankulov <
> > > > >>>>>>>>>>> erixon...@gmail.com>:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Hi, Pavel
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Is it possible to provide type-safe API for
> > > > >>>>>>>>>> ServiceProxyContext ?
> > > > >>>>>>>>>>>>>>>> I think constructions like int arg1 =
> > > > >>>>>>>> ctx.attribute("arg1");
> > > > >>>>>>>>>> are
> > > > >>>>>>>>>>>>> error
> > > > >>>>>>>>>>>>>>>> prone.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Can we make something like this :
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> //Signature with two generic params which allow the
> > > > >>>>>>>> compiler
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>> check
> > > > >>>>>>>>>>>>>>>> if the service will be called with the wrong type
> > > > >>>>>>> context.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> public <T extends ContextedWith<CtxType>, CtxType> T
> > > > >>>>>>>>>>>>>>>> serviceProxyTyped(ClusterGroup prj, String name,
> Class<?
> > > > >>>>>>>>> super
> > > > >>>>>>>>>> T
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> srvcCls, CtxType optCtx, boolean sticky, long
> timeout)
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> //new interface which services with scoped context
> > > should
> > > > >>>>>>>>>>> implement
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> public interface ContextedWith<T> {
> > > > >>>>>>>>>>>>>>>> T getCtx();
> > > > >>>>>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> // implementation can delegate to Map-like context
> or be
> > > > >>>>>>>>> POJO.
> > > > >>>>>>>>>>>>>>>> interface MyServiceContext {
> > > > >>>>>>>>>>>>>>>> int getArg1();
> > > > >>>>>>>>>>>>>>>> String getUserId();
> > > > >>>>>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> class MyService implements
> > > > >>>>>>> ContextedWith<MyServiceContext>
> > > > >>>>>>>> {
> > > > >>>>>>>>>>>>>>>> void doThings() {
> > > > >>>>>>>>>>>>>>>> MyServiceContext ctx = getCtx();
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> System.out.println("ctx.getArg1() = " +
> ctx.getArg1());
> > > > >>>>>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> @Override public MyServiceContext getCtx() {
> > > > >>>>>>>>>>>>>>>> return ServiceProxyContext.current();
> > > > >>>>>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> WDYT?
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Best regards, Ed.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin <
> > > > >>>>>>>>>> xxt...@gmail.com>
> > > > >>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Hello Igniters!
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I want to implement a feature to support a custom
> > > > >>>>>>>> "caller"
> > > > >>>>>>>>>>> context
> > > > >>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>> ignite services (see example in ticket description
> > > > >>>>>>> [1]).
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Sometimes, when using Ignite services, it becomes
> > > > >>>>>>>> necessary
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>> pass
> > > > >>>>>>>>>>>>>>>>> custom parameters from the "request source" to the
> > > > >>>>>>>> service.
> > > > >>>>>>>>>>> This is
> > > > >>>>>>>>>>>>>>>>> most commonly used to track the origin of a service
> > > > >>>>>>> call
> > > > >>>>>>>>>> (user
> > > > >>>>>>>>>>> id,
> > > > >>>>>>>>>>>>>>>>> request id, session id eg see this user question
> [2]).
> > > > >>>>>>>>>>>>>>>>> At the moment, the only way to pass such
> parameters to
> > > > >>>>>>> a
> > > > >>>>>>>>>>> service is
> > > > >>>>>>>>>>>>>> by
> > > > >>>>>>>>>>>>>>>>> adding argument(s) to all called methods of the
> > > > >>>>>>> service,
> > > > >>>>>>>>>> which
> > > > >>>>>>>>>>>>> makes
> > > > >>>>>>>>>>>>>>>>> the code messy and also complicates development and
> > > > >>>>>>>>>>> maintenance.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I propose letting the user set a custom context
> for the
> > > > >>>>>>>>>> service
> > > > >>>>>>>>>>>>> proxy
> > > > >>>>>>>>>>>>>>>>> and implicitly pass that context to the methods
> being
> > > > >>>>>>>>> called.
> > > > >>>>>>>>>>> This
> > > > >>>>>>>>>>>>>>>>> function should not affect the execution of service
> > > > >>>>>>>> methods
> > > > >>>>>>>>>> in
> > > > >>>>>>>>>>> any
> > > > >>>>>>>>>>>>>> way
> > > > >>>>>>>>>>>>>>>>> unless the user has specified a context.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> An example of using the proposed API [1].
> > > > >>>>>>>>>>>>>>>>> PoC (except thin clients) [3].
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> WDYT?
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> [1]
> https://issues.apache.org/jira/browse/IGNITE-15572
> > > > >>>>>>>>>>>>>>>>> [2]
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
> > > > >>>>>>>>>>>>>>>>> [3] https://github.com/apache/ignite/pull/9440
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Sincerely yours, Ivan Daschinskiy
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> Sincerely yours, Ivan Daschinskiy
> > > > >>
> > > >
> > > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> > >
>
