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

Reply via email to