Thank you all for your replies!
I got the idea and agreed with it. Based on the results of the
discussion, I have filed a ticket [1].
I will try to investigate it.
[1] - https://issues.apache.org/jira/browse/IGNITE-16157
On 16.12.2021 20:11, Ivan Daschinsky wrote:
Andrey, agree with you, good
Pavel,
As for option (1): the count of methods will increase in geometric
progression with each new parameter. For example, if we decide to add
tracing to services, we should keep current methods as-is for backward
compatibility and add new methods supporting a tracing parameter.
> Also, we don't
Cancelling the vote.
I'll cherry-pick the following [1] to the release branch and prepare a
new RC today.
[1] https://issues.apache.org/jira/browse/IGNITE-16153
Hi,
Why is ignite rest module still using old log4j version dependency?
https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/log4j/pom.xml#L46
Can this be removed ? There is a critical CVE against this package.
Regards,
Vishwas
On Wed, 15 Dec, 2021, 12:57 Ale
Correct url to rest-http module
https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/rest-http/pom.xml#L131
On Mon, 20 Dec, 2021, 16:06 Vishwas Bm, wrote:
> Hi,
>
> Why is ignite rest module still using old log4j version dependency?
>
>
> https://github.com/apa
Maxim,
Look like an issue is not related to security problems we fix.
Any reason to cancel the vote (delay release) to include this bugfix?
On Mon, Dec 20, 2021 at 1:28 PM Maxim Muzafarov wrote:
> Cancelling the vote.
>
> I'll cherry-pick the following [1] to the release branch and prepare a
> n
What do you mean, Anton? This is quite dangerous vulnerability and it is
recommended to update log4j asap.
пн, 20 дек. 2021 г. в 14:00, Anton Vinogradov :
> Maxim,
> Look like an issue is not related to security problems we fix.
> Any reason to cancel the vote (delay release) to include this bugf
The ability to kill applications is less important than gaining access.
We may release 2.11.2 if necessary.
But now we must release 2.11.1 asap because it fixes a critical security
issue.
On Mon, Dec 20, 2021 at 2:01 PM Ivan Daschinsky wrote:
> What do you mean, Anton? This is quite dangerous vu
Alex,
> the count of methods will increase in geometric progression
I would say it is linear, not geometric.
Anyway, a common fix for "too many parameters" issue is Parameter Object
pattern [1],
I suggest introducing "ServiceProxyConfiguration" class.
> We already using such an approach in tran
The second release candidate for the 2.11.1 version is ready.
Since this is an emergency release the vote will remain open for as
short an amount as time as required to vet the release. All votes are
welcome and we encourage everyone to test the release, but only PMC
votes are “officially” counted
Hello!
+1
There seems to be a correct version of log4j2 now.
Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
quite bad.
Regards,
--
Ilya Kasnacheev
пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
> The second release candidate for the 2.11.1 version is ready.
>
> Sinc
+1
Checked .NET binaries, nugets, and examples.
On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev
wrote:
> Hello!
>
> +1
>
> There seems to be a correct version of log4j2 now.
>
> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
> quite bad.
>
> Regards,
> --
> Ilya Kasnach
Vishwas Bm,
I've found the same for the Zookeeper IP finder module.
It seems to me that it must be fixed also.
[1] https://github.com/apache/ignite/blob/master/modules/zookeeper/pom.xml#L114
On Mon, 20 Dec 2021 at 13:39, Vishwas Bm wrote:
>
> Correct url to rest-http module
>
> https://github.
+1 from me
Checked ODBC drivers (32-bit and 64-bit) installers on Windows with running
locally Ignite with
pyodbc and python 3.9 using this script [1]
[1] -- https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa
пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :
> +1
>
> Checked .NET bi
+1 (binding)
> 20 дек. 2021 г., в 16:20, Ivan Daschinsky написал(а):
>
> +1 from me
> Checked ODBC drivers (32-bit and 64-bit) installers on Windows with running
> locally Ignite with
> pyodbc and python 3.9 using this script [1]
>
>
> [1] -- https://gist.github.com/ivandasch/6cc0b56e055b826e5
Hello,
+1
Thanks,
S.
пн, 20 дек. 2021 г. в 16:26, Nikolay Izhikov :
> +1 (binding)
>
> > 20 дек. 2021 г., в 16:20, Ivan Daschinsky
> написал(а):
> >
> > +1 from me
> > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with
> running
> > locally Ignite with
> > pyodbc and python 3.
+1
Checked build from the source, cluster startup with 2 nodes.
пн, 20 дек. 2021 г. в 16:27, Nikolay Izhikov :
> +1 (binding)
>
> > 20 дек. 2021 г., в 16:20, Ivan Daschinsky
> написал(а):
> >
> > +1 from me
> > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with
> running
> > lo
Pavel,
> Can you clarify please, is it going to be a new interface, let's say
> IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"?
Yes, that's what I meant (if we go this way).
пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn :
>
> Alex,
>
> > the count of methods will inc
Pavel,
> I would say it is linear, not geometric.
Without service context, there were 2 serviceProxy methods. The patch with
service contexts adds two more methods. Each next parameter according to
this pattern will add the same amount of methods as there were before.
> I suggest introducing "Ser
Andrey, I believe that we already have all machinery to do migration safe.
See for
example
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
and
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
This machinery was intr
Ivan,
I'm still not sure it is a good idea to upgrade metastorage automatically.
Because we can't detect the correct charset the metastorage was created
with, and
at the same time we can't be sure the current charset is the correct one.
So, is there any guarantee the metastorage is consistent eve
Hi, Ivan.
> it seems not bulletproof
I completely agree with you. As I wrote in the original message, this
becomes even worse in case of 3-rd party dependencies, because they may not
be annotated, which can lead to confusions. But looks like this is not a
big deal, because these annotations are n
We copy values unchanged as is in bytes representation. Could you please
specify what could be done wrong?
I see only one possibility:
1. Start cluster with default encoding (This is only the windows case :)).
Set some metastorage values with non ASCII chars.
2. Stop it and restart with specifying
+1
On Mon, Dec 20, 2021 at 5:39 AM Alex Plehanov
wrote:
> +1
>
> Checked build from the source, cluster startup with 2 nodes.
>
> пн, 20 дек. 2021 г. в 16:27, Nikolay Izhikov :
>
> > +1 (binding)
> >
> > > 20 дек. 2021 г., в 16:20, Ivan Daschinsky
> > написал(а):
> > >
> > > +1 from me
> > > Ch
Neither solution is completely bulletproof, and I don't think that's what
we are looking for. We need something that provides a reasonable value, but
also does not clutter the code with too many annotations.
I would also keep in mind that annotations are used not only for static
analysis, but by d
Val,
> Therefore, it's crucial to bring the attention of the API's user to such
> parameters. (@Nullable)
This sounds wrong for me. If a method parameter is marked as
@Nullable, then a user can put anything there without much thinking.
Opposite happens with @NotNull parameters, with them a user
26 matches
Mail list logo
