Hello Ignite community!
My name is Roman Puchkovskiy. I would like to contribute to Apache
Ignite. My Apache JIRA username is rpuch.
Could you please provide me with the corresponding permission?
Roman Puchkovskiy
(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(...)
Hello, Roman!
I have added you to the Contributors role, you may now assign issues to
yourself.
Please make sure to follow
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
Regards,
--
Ilya Kasnacheev
вт, 19 окт. 2021 г. в 10:48, Roman Puchkovskiy :
> Hello Ignite communit
I like (1) options.
@ServiceRequestContextResource
private Function 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:0
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 :
> I like (1) options.
>
>@ServiceRequestContextResource
>private Function ctxFunc;
>
> Becau
Generation is a good one.
Also we can use variant from DEB packaging versioning — EPOCH.
> On 17 Oct 2021, at 02:52, Valentin Kulichenko
> wrote:
>
> Folks,
>
> Since there are controversial opinions regarding the topic, I've cancelled
> the vote and would like to resurrect the discussion.
>
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
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 a
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
> Removing parameters from a public interface method is a breaking change,
> or do you mean something else?
Sorry, I meant that we can inject the service context, but leave it
available in the init/execute/cancel methods and add a default "no-op"
implementation in the interface for them. Can we do
That's actually a good point. In Java, we can do the following:
1. Add init/execute/cancel methods without parameters.
2. Add default no-op implementations for the new methods (this is required
to preserve compatibility).
3. For old methods that take ServiceContext as a parameter, add default
imple
> and it fully switches to annotation-based injection.
+1 to do it.
> 19 окт. 2021 г., в 22:14, Valentin Kulichenko
> написал(а):
>
> That's actually a good point. In Java, we can do the following:
> 1. Add init/execute/cancel methods without parameters.
> 2. Add default no-op implementations
12 matches
Mail list logo
