[jira] [Created] (IGNITE-3323) Get rid of copypasted JB annotations, use dependency instead.

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-3323:


 Summary: Get rid of copypasted JB annotations, use dependency 
instead.
 Key: IGNITE-3323
 URL: https://issues.apache.org/jira/browse/IGNITE-3323
 Project: Ignite
  Issue Type: Task
Affects Versions: 1.5.0.final
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov
Priority: Minor
 Fix For: 1.7


>From user request: 

{quote}
I've come across an issue where there are a couple of classes duplicated from 
org.jetbrains.annotations within the ignite-core module which conflict with 
other part of our code base.

As these files are duplicated rather than being referenced as a maven 
dependency I am unable to exclude them or reference a specific version of the 
org.jetbrains.annotations artifact.

Specifically, the included version cannot be used to annotate types
ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER, 
ElementType.LOCAL_VARIABLE})
annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER, 
ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})

As far as I know there isn't an easy way of excluding these files from within 
the ignite-core module. Is there are reason why these "external" files have 
been duplicated within the ignite code base rather than being referenced as a 
maven dependency? Or alternatively, has anyone come across a way of avoiding 
these conflicts?
{quote}

Seems we have to remove these classes from Ignite code and use maven dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Maven conflicts within ignite-core from duplicated classes

[Anton Vinogradov]

Denis,

I've created issue: https://issues.apache.org/jira/browse/IGNITE-3323

On Mon, Jun 13, 2016 at 10:04 AM, Denis Magda  wrote:

> Hi Pete,
>
> CC-ing Ignite dev list to the thread as well.
>
> Igniters, up to today is there any reason why we need to include sources
> of Nullable JetBrain’s annotation in Ignite sources?
>
> As I see we can rather import that latest version from the maven repository
> https://maven-repository.com/artifact/org.jetbrains/annotations/15.0
>
> *Anton, *please take a look at Pete issue and suggest a workaround and
> generic solution overall.
>
> —
> Denis
>
> On Jun 9, 2016, at 1:32 PM, Pete Campton  wrote:
>
> Hello,
>
> I've come across an issue where there are a couple of classes duplicated
> from org.jetbrains.annotations within the ignite-core module which conflict
> with other part of our code base.
>
> As these files are duplicated rather than being referenced as a maven
> dependency I am unable to exclude them or reference a specific version of
> the org.jetbrains.annotations artifact.
>
> Specifically, the included version cannot be used to annotate types
> ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> ElementType.LOCAL_VARIABLE})
> annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})
>
> As far as I know there isn't an easy way of excluding these files from
> within the ignite-core module. Is there are reason why these "external"
> files have been duplicated within the ignite code base rather than being
> referenced as a maven dependency? Or alternatively, has anyone come across
> a way of avoiding these conflicts?
>
> Thanks
> Pete
>
>
>

Re: Maven conflicts within ignite-core from duplicated classes

[Semyon Boikov]

As far as I know the only reason sources of Nullable are in Ignite - we did
not want to have any dependecy for 'core' module.

On Mon, Jun 13, 2016 at 10:04 AM, Denis Magda  wrote:

> Hi Pete,
>
> CC-ing Ignite dev list to the thread as well.
>
> Igniters, up to today is there any reason why we need to include sources
> of Nullable JetBrain’s annotation in Ignite sources?
>
> As I see we can rather import that latest version from the maven repository
> https://maven-repository.com/artifact/org.jetbrains/annotations/15.0
>
> *Anton, *please take a look at Pete issue and suggest a workaround and
> generic solution overall.
>
> —
> Denis
>
> On Jun 9, 2016, at 1:32 PM, Pete Campton  wrote:
>
> Hello,
>
> I've come across an issue where there are a couple of classes duplicated
> from org.jetbrains.annotations within the ignite-core module which conflict
> with other part of our code base.
>
> As these files are duplicated rather than being referenced as a maven
> dependency I am unable to exclude them or reference a specific version of
> the org.jetbrains.annotations artifact.
>
> Specifically, the included version cannot be used to annotate types
> ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> ElementType.LOCAL_VARIABLE})
> annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})
>
> As far as I know there isn't an easy way of excluding these files from
> within the ignite-core module. Is there are reason why these "external"
> files have been duplicated within the ignite code base rather than being
> referenced as a maven dependency? Or alternatively, has anyone come across
> a way of avoiding these conflicts?
>
> Thanks
> Pete
>
>
>

Re: Maven conflicts within ignite-core from duplicated classes

[Vladislav Pyatkov]

Why not just rename these classes?

On Thu, Jun 16, 2016 at 11:16 AM, Semyon Boikov 
wrote:

> As far as I know the only reason sources of Nullable are in Ignite - we
> did not want to have any dependecy for 'core' module.
>
> On Mon, Jun 13, 2016 at 10:04 AM, Denis Magda  wrote:
>
>> Hi Pete,
>>
>> CC-ing Ignite dev list to the thread as well.
>>
>> Igniters, up to today is there any reason why we need to include sources
>> of Nullable JetBrain’s annotation in Ignite sources?
>>
>> As I see we can rather import that latest version from the maven
>> repository
>> https://maven-repository.com/artifact/org.jetbrains/annotations/15.0
>>
>> *Anton, *please take a look at Pete issue and suggest a workaround and
>> generic solution overall.
>>
>> —
>> Denis
>>
>> On Jun 9, 2016, at 1:32 PM, Pete Campton  wrote:
>>
>> Hello,
>>
>> I've come across an issue where there are a couple of classes duplicated
>> from org.jetbrains.annotations within the ignite-core module which conflict
>> with other part of our code base.
>>
>> As these files are duplicated rather than being referenced as a maven
>> dependency I am unable to exclude them or reference a specific version of
>> the org.jetbrains.annotations artifact.
>>
>> Specifically, the included version cannot be used to annotate types
>> ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
>> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
>> ElementType.LOCAL_VARIABLE})
>> annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
>> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
>> ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})
>>
>> As far as I know there isn't an easy way of excluding these files from
>> within the ignite-core module. Is there are reason why these "external"
>> files have been duplicated within the ignite code base rather than being
>> referenced as a maven dependency? Or alternatively, has anyone come across
>> a way of avoiding these conflicts?
>>
>> Thanks
>> Pete
>>
>>
>>
>

Re: Maven conflicts within ignite-core from duplicated classes

[Vladimir Ozerov]

And why do we afraid this dependency? It has "CLASS" retention so users do
not need them in runtime, AFAIK.

On Thu, Jun 16, 2016 at 11:19 AM, Vladislav Pyatkov 
wrote:

> Why not just rename these classes?
>
> On Thu, Jun 16, 2016 at 11:16 AM, Semyon Boikov 
> wrote:
>
> > As far as I know the only reason sources of Nullable are in Ignite - we
> > did not want to have any dependecy for 'core' module.
> >
> > On Mon, Jun 13, 2016 at 10:04 AM, Denis Magda 
> wrote:
> >
> >> Hi Pete,
> >>
> >> CC-ing Ignite dev list to the thread as well.
> >>
> >> Igniters, up to today is there any reason why we need to include sources
> >> of Nullable JetBrain’s annotation in Ignite sources?
> >>
> >> As I see we can rather import that latest version from the maven
> >> repository
> >> https://maven-repository.com/artifact/org.jetbrains/annotations/15.0
> >>
> >> *Anton, *please take a look at Pete issue and suggest a workaround and
> >> generic solution overall.
> >>
> >> —
> >> Denis
> >>
> >> On Jun 9, 2016, at 1:32 PM, Pete Campton 
> wrote:
> >>
> >> Hello,
> >>
> >> I've come across an issue where there are a couple of classes duplicated
> >> from org.jetbrains.annotations within the ignite-core module which
> conflict
> >> with other part of our code base.
> >>
> >> As these files are duplicated rather than being referenced as a maven
> >> dependency I am unable to exclude them or reference a specific version
> of
> >> the org.jetbrains.annotations artifact.
> >>
> >> Specifically, the included version cannot be used to annotate types
> >> ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
> >> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> >> ElementType.LOCAL_VARIABLE})
> >> annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
> >> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> >> ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})
> >>
> >> As far as I know there isn't an easy way of excluding these files from
> >> within the ignite-core module. Is there are reason why these "external"
> >> files have been duplicated within the ignite code base rather than being
> >> referenced as a maven dependency? Or alternatively, has anyone come
> across
> >> a way of avoiding these conflicts?
> >>
> >> Thanks
> >> Pete
> >>
> >>
> >>
> >
>

[jira] [Created] (IGNITE-3324) .NET: LINQPad Data Context Driver

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3324:
--

 Summary: .NET: LINQPad Data Context Driver
 Key: IGNITE-3324
 URL: https://issues.apache.org/jira/browse/IGNITE-3324
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Priority: Minor


LINQPad can be extended with a custom Data Context Driver: 
http://www.linqpad.net/Extensibility.aspx

With SQL databases, this displays a tree view (top left) of databases, tables, 
columns, and allows easy strongly-typed queries, as well as raw SQL queries in 
some cases.

In our case, I imagine the following:
* User connects to the grid with our Ignite LINQPad Driver
* List of queryable entities is displayed (one per QueryEntity) - for SQL and 
LINQ queries
* Separate list of all caches is displayed (regardless of query configuration) 
- for LINQ-to-objects and other raw cache operations (in binary mode only)

This is a low priority integration, but nice and fun one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Change rest-http Java to JSON null transformation logic

[Alexey Kuznetsov]

Hi All!

I'm working on migrating from outdated json-lib to Jackson issue
IGNITE-3277 [1] and found that previous library serialize null strings as
"" and null objects as "null", for example:
{"a": "", "b": null}

How about to serialize all values as "null" ?
In this case we would definitely know that in Java before serialization to
JSON was really NULL, not empty string.

But this may break compatibility in some cases.

Thoughts?


1. https://issues.apache.org/jira/browse/IGNITE-3277

-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-3325) .NET: LINQ Take method does not work within CompiledQuery

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3325:
--

 Summary: .NET: LINQ Take method does not work within CompiledQuery
 Key: IGNITE-3325
 URL: https://issues.apache.org/jira/browse/IGNITE-3325
 Project: Ignite
  Issue Type: Bug
  Components: community, platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
 Fix For: 1.7


User reported that the following code fails with "Error compiling query: all 
compiled query arguments should come from enclosing delegate parameters."
{code}
Func>> qry = 
CompiledQuery.Compile((int x, int y,int z) => 
orderCache.AsCacheQueryable().Where(e => e.Value.OrderId % x == z).Take(y));
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Change rest-http Java to JSON null transformation logic

[Vladislav Pyatkov]

Hello,

Why do you want this, if you can save full compatibility using custom
serializer for null value (ObjectMapper#setSerializerProvider)?

On Thu, Jun 16, 2016 at 12:15 PM, Alexey Kuznetsov 
wrote:

> Hi All!
>
> I'm working on migrating from outdated json-lib to Jackson issue
> IGNITE-3277 [1] and found that previous library serialize null strings as
> "" and null objects as "null", for example:
> {"a": "", "b": null}
>
> How about to serialize all values as "null" ?
> In this case we would definitely know that in Java before serialization to
> JSON was really NULL, not empty string.
>
> But this may break compatibility in some cases.
>
> Thoughts?
>
>
> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[GitHub] ignite pull request #807: Ignite 3233

[alexpaschenko]

Github user alexpaschenko closed the pull request at:

https://github.com/apache/ignite/pull/807


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #796: IGNITE-3151 I rework fixation, so that there was n...

[vldpyatkov]

Github user vldpyatkov closed the pull request at:

https://github.com/apache/ignite/pull/796


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Change rest-http Java to JSON null transformation logic

[Pavel Tupitsyn]

Hi,

What if there is an actual string with "null" value?

Pavel.

On Thu, Jun 16, 2016 at 12:44 PM, Vladislav Pyatkov 
wrote:

> Hello,
>
> Why do you want this, if you can save full compatibility using custom
> serializer for null value (ObjectMapper#setSerializerProvider)?
>
> On Thu, Jun 16, 2016 at 12:15 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com> wrote:
>
>> Hi All!
>>
>> I'm working on migrating from outdated json-lib to Jackson issue
>> IGNITE-3277 [1] and found that previous library serialize null strings as
>> "" and null objects as "null", for example:
>> {"a": "", "b": null}
>>
>> How about to serialize all values as "null" ?
>> In this case we would definitely know that in Java before serialization
>> to JSON was really NULL, not empty string.
>>
>> But this may break compatibility in some cases.
>>
>> Thoughts?
>>
>>
>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com
>>
>
>

Re: Change rest-http Java to JSON null transformation logic

[Denis Magda]

This looks strange. Definitely for consistency reasons it makes sense that all 
‘null’ objects including string are serialized as “null”.

In regards to the compatibility stuff I think it can be resolved somehow. 

—
Denis

> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov  
> wrote:
> 
> Hi All!
> 
> I'm working on migrating from outdated json-lib to Jackson issue IGNITE-3277 
> [1] and found that previous library serialize null strings as "" and null 
> objects as "null", for example:
> {"a": "", "b": null}
> 
> How about to serialize all values as "null" ?
> In this case we would definitely know that in Java before serialization to 
> JSON was really NULL, not empty string.
> 
> But this may break compatibility in some cases.
> 
> Thoughts?
> 
> 
> 1. https://issues.apache.org/jira/browse/IGNITE-3277 
> 
> 
> -- 
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com 

Re: Change rest-http Java to JSON null transformation logic

[Pavel Tupitsyn]

Why do we even write null fields? Can we just omit them?
This will be faster, more compact, and less ambiguous.

Pavel.

On Thu, Jun 16, 2016 at 12:51 PM, Denis Magda  wrote:

> This looks strange. Definitely for consistency reasons it makes sense that
> all ‘null’ objects including string are serialized as “null”.
>
> In regards to the compatibility stuff I think it can be resolved somehow.
>
> —
> Denis
>
> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov 
> wrote:
>
> Hi All!
>
> I'm working on migrating from outdated json-lib to Jackson issue
> IGNITE-3277 [1] and found that previous library serialize null strings as
> "" and null objects as "null", for example:
> {"a": "", "b": null}
>
> How about to serialize all values as "null" ?
> In this case we would definitely know that in Java before serialization to
> JSON was really NULL, not empty string.
>
> But this may break compatibility in some cases.
>
> Thoughts?
>
>
> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
>
>

Re: Change rest-http Java to JSON null transformation logic

[Alexey Kuznetsov]

Vlad,

Actually I implemented 2 custom serializers: one for null strings and
another for null objects.
But I think that it looks like a "workaround" for me.

On Thu, Jun 16, 2016 at 4:44 PM, Vladislav Pyatkov 
wrote:

> Hello,
>
> Why do you want this, if you can save full compatibility using custom
> serializer for null value (ObjectMapper#setSerializerProvider)?
>
> On Thu, Jun 16, 2016 at 12:15 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com> wrote:
>
>> Hi All!
>>
>> I'm working on migrating from outdated json-lib to Jackson issue
>> IGNITE-3277 [1] and found that previous library serialize null strings as
>> "" and null objects as "null", for example:
>> {"a": "", "b": null}
>>
>> How about to serialize all values as "null" ?
>> In this case we would definitely know that in Java before serialization
>> to JSON was really NULL, not empty string.
>>
>> But this may break compatibility in some cases.
>>
>> Thoughts?
>>
>>
>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com
>>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[GitHub] ignite pull request #808: ignite-3239 Fix of java.io.IOException: Resource d...

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/808

ignite-3239 Fix of java.io.IOException: Resource deadlock avoided



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-3239

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/808.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #808


commit e33979f0f2d5bf408a60ac7d5297a057fe75c129
Author: agura 
Date:   2016-06-16T10:03:03Z

ignite-3239 Fix of java.io.IOException: Resource deadlock avoided




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Change rest-http Java to JSON null transformation logic

[Alexey Kuznetsov]

Pavel, in this case object will be serialized like : {"a": "null"} compare
with {"a": null}

On Thu, Jun 16, 2016 at 4:49 PM, Pavel Tupitsyn 
wrote:

> Hi,
>
> What if there is an actual string with "null" value?
>
> Pavel.
>
> On Thu, Jun 16, 2016 at 12:44 PM, Vladislav Pyatkov  > wrote:
>
>> Hello,
>>
>> Why do you want this, if you can save full compatibility using custom
>> serializer for null value (ObjectMapper#setSerializerProvider)?
>>
>> On Thu, Jun 16, 2016 at 12:15 PM, Alexey Kuznetsov <
>> akuznet...@gridgain.com> wrote:
>>
>>> Hi All!
>>>
>>> I'm working on migrating from outdated json-lib to Jackson issue
>>> IGNITE-3277 [1] and found that previous library serialize null strings as
>>> "" and null objects as "null", for example:
>>> {"a": "", "b": null}
>>>
>>> How about to serialize all values as "null" ?
>>> In this case we would definitely know that in Java before serialization
>>> to JSON was really NULL, not empty string.
>>>
>>> But this may break compatibility in some cases.
>>>
>>> Thoughts?
>>>
>>>
>>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>>
>>> --
>>> Alexey Kuznetsov
>>> GridGain Systems
>>> www.gridgain.com
>>>
>>
>>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Change rest-http Java to JSON null transformation logic

[Alexey Kuznetsov]

Pavel, we cannot omit them.

Because if JSON will be transformed back to Java and some java field has
not null default value that will lead to not correct de-serialization in
this case.

On Thu, Jun 16, 2016 at 4:54 PM, Pavel Tupitsyn 
wrote:

> Why do we even write null fields? Can we just omit them?
> This will be faster, more compact, and less ambiguous.
>
> Pavel.
>
> On Thu, Jun 16, 2016 at 12:51 PM, Denis Magda  wrote:
>
>> This looks strange. Definitely for consistency reasons it makes sense
>> that all ‘null’ objects including string are serialized as “null”.
>>
>> In regards to the compatibility stuff I think it can be resolved somehow.
>>
>> —
>> Denis
>>
>> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov 
>> wrote:
>>
>> Hi All!
>>
>> I'm working on migrating from outdated json-lib to Jackson issue
>> IGNITE-3277 [1] and found that previous library serialize null strings as
>> "" and null objects as "null", for example:
>> {"a": "", "b": null}
>>
>> How about to serialize all values as "null" ?
>> In this case we would definitely know that in Java before serialization
>> to JSON was really NULL, not empty string.
>>
>> But this may break compatibility in some cases.
>>
>> Thoughts?
>>
>>
>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com
>>
>>
>>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Change rest-http Java to JSON null transformation logic

[Pavel Tupitsyn]

Alexey, got it regarding "null" string, thank you.

Can you elaborate on non-null default values? Is it only for primitive
types, or something else?
Anyway, can we omit fields with default values? I have seen some
serializers that work this way.

Pavel.

On Thu, Jun 16, 2016 at 1:05 PM, Alexey Kuznetsov 
wrote:

> Pavel, we cannot omit them.
>
> Because if JSON will be transformed back to Java and some java field has
> not null default value that will lead to not correct de-serialization in
> this case.
>
> On Thu, Jun 16, 2016 at 4:54 PM, Pavel Tupitsyn 
> wrote:
>
>> Why do we even write null fields? Can we just omit them?
>> This will be faster, more compact, and less ambiguous.
>>
>> Pavel.
>>
>> On Thu, Jun 16, 2016 at 12:51 PM, Denis Magda 
>> wrote:
>>
>>> This looks strange. Definitely for consistency reasons it makes sense
>>> that all ‘null’ objects including string are serialized as “null”.
>>>
>>> In regards to the compatibility stuff I think it can be resolved
>>> somehow.
>>>
>>> —
>>> Denis
>>>
>>> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov 
>>> wrote:
>>>
>>> Hi All!
>>>
>>> I'm working on migrating from outdated json-lib to Jackson issue
>>> IGNITE-3277 [1] and found that previous library serialize null strings as
>>> "" and null objects as "null", for example:
>>> {"a": "", "b": null}
>>>
>>> How about to serialize all values as "null" ?
>>> In this case we would definitely know that in Java before serialization
>>> to JSON was really NULL, not empty string.
>>>
>>> But this may break compatibility in some cases.
>>>
>>> Thoughts?
>>>
>>>
>>> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>>>
>>> --
>>> Alexey Kuznetsov
>>> GridGain Systems
>>> www.gridgain.com
>>>
>>>
>>>
>>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Change rest-http Java to JSON null transformation logic

[Alexey Kuznetsov]

Den, that was my main reason "consistency". Strings in java can be "null"
and can be empty. But after serialization we lost this info.
As for compatibility - I'm afraid it is impossible to fix. Only to change
user code.

On Thu, Jun 16, 2016 at 4:51 PM, Denis Magda  wrote:

> This looks strange. Definitely for consistency reasons it makes sense that
> all ‘null’ objects including string are serialized as “null”.
>
> In regards to the compatibility stuff I think it can be resolved somehow.
>
> —
> Denis
>
> On Jun 16, 2016, at 12:15 PM, Alexey Kuznetsov 
> wrote:
>
> Hi All!
>
> I'm working on migrating from outdated json-lib to Jackson issue
> IGNITE-3277 [1] and found that previous library serialize null strings as
> "" and null objects as "null", for example:
> {"a": "", "b": null}
>
> How about to serialize all values as "null" ?
> In this case we would definitely know that in Java before serialization to
> JSON was really NULL, not empty string.
>
> But this may break compatibility in some cases.
>
> Thoughts?
>
>
> 1. https://issues.apache.org/jira/browse/IGNITE-3277
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Maven conflicts within ignite-core from duplicated classes

[Anton Vinogradov]

We already have 2 dependencies at ignite-core:
*javax.cache.cache-api* and *org.gridgain.ignite-shmem*
(ASAIK we have an issue to redeploy org.gridgain.ignite-shmem as
org.apache.ignite.ignite-shmem)

On Thu, Jun 16, 2016 at 11:57 AM, Vladimir Ozerov 
wrote:

> And why do we afraid this dependency? It has "CLASS" retention so users do
> not need them in runtime, AFAIK.
>
> On Thu, Jun 16, 2016 at 11:19 AM, Vladislav Pyatkov  >
> wrote:
>
> > Why not just rename these classes?
> >
> > On Thu, Jun 16, 2016 at 11:16 AM, Semyon Boikov 
> > wrote:
> >
> > > As far as I know the only reason sources of Nullable are in Ignite - we
> > > did not want to have any dependecy for 'core' module.
> > >
> > > On Mon, Jun 13, 2016 at 10:04 AM, Denis Magda 
> > wrote:
> > >
> > >> Hi Pete,
> > >>
> > >> CC-ing Ignite dev list to the thread as well.
> > >>
> > >> Igniters, up to today is there any reason why we need to include
> sources
> > >> of Nullable JetBrain’s annotation in Ignite sources?
> > >>
> > >> As I see we can rather import that latest version from the maven
> > >> repository
> > >> https://maven-repository.com/artifact/org.jetbrains/annotations/15.0
> > >>
> > >> *Anton, *please take a look at Pete issue and suggest a workaround and
> > >> generic solution overall.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> On Jun 9, 2016, at 1:32 PM, Pete Campton 
> > wrote:
> > >>
> > >> Hello,
> > >>
> > >> I've come across an issue where there are a couple of classes
> duplicated
> > >> from org.jetbrains.annotations within the ignite-core module which
> > conflict
> > >> with other part of our code base.
> > >>
> > >> As these files are duplicated rather than being referenced as a maven
> > >> dependency I am unable to exclude them or reference a specific version
> > of
> > >> the org.jetbrains.annotations artifact.
> > >>
> > >> Specifically, the included version cannot be used to annotate types
> > >> ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ...
> > >> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> > >> ElementType.LOCAL_VARIABLE})
> > >> annotations-15.0.jar:org.jetbrains.annotations.Nullable ...
> > >> @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER,
> > >> ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE})
> > >>
> > >> As far as I know there isn't an easy way of excluding these files from
> > >> within the ignite-core module. Is there are reason why these
> "external"
> > >> files have been duplicated within the ignite code base rather than
> being
> > >> referenced as a maven dependency? Or alternatively, has anyone come
> > across
> > >> a way of avoiding these conflicts?
> > >>
> > >> Thanks
> > >> Pete
> > >>
> > >>
> > >>
> > >
> >
>

[GitHub] ignite pull request #804: Ignite gg 11237

[avinogradovgg]

Github user avinogradovgg closed the pull request at:

https://github.com/apache/ignite/pull/804


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #806: IGNITE-3317 .NET: Improve error message when jvm.d...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/806


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3326) Map-reduce query waits for rebalancing forever when it's disabled.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-3326:
-

 Summary: Map-reduce query waits for rebalancing forever when it's 
disabled.
 Key: IGNITE-3326
 URL: https://issues.apache.org/jira/browse/IGNITE-3326
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
Priority: Minor


The code below doesn't print anything:

{code}
public static void main(String[] args) throws IgniteException {
Ignite start = Ignition.start(new IgniteConfiguration());
CacheConfiguration cfg = new CacheConfiguration<>();
cfg.setRebalanceMode(CacheRebalanceMode.NONE);
cfg.setCacheMode(CacheMode.PARTITIONED);
cfg.setName("test");
cfg.setIndexedTypes(Integer.class, Person.class);
IgniteCache cache = start.createCache(cfg);
cache.put(1, new Person(1L, "Test 1", "Test 1"));
cache.put(2, new Person(1L, "Test 2", "Test 2"));
cache.put(3, new Person(1L, "Test 3", "Test 3"));

QueryCursor> query = cache.query(new 
SqlQuery(Person.class, "_key >= 0"));
List> all = query.getAll();

System.out.println(all);
}
{code}

Suggested fix: disable reservation if rebalancing is disabled.
In GridMapQueryExecutor.reservePartitions add

if (cctx.isLocal() || !cctx.rebalanceEnabled())
continue;




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Merged: When multiple addresses resolve to same name, TcpDiscoverySharedFsIpFinder fails on unregister

[Denis Magda]

Kristian,

Thanks again for improving Apache Ignite. I’ve just reviewed and merged your 
pull request.
https://github.com/apache/ignite/pull/799/files 


Waiting for more contributions from your side!

—
Denis

[jira] [Created] (IGNITE-3327) .NET: Pass all logging through Java side

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3327:
--

 Summary: .NET: Pass all logging through Java side
 Key: IGNITE-3327
 URL: https://issues.apache.org/jira/browse/IGNITE-3327
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


Logging from any platform should go through Java so that standard file log 
captures everything.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request #782: IGNITE-3105 .NET: Fix ContinuousQueryAbstractTest....

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/782


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #748: IGNITE-3182 Compute jobs execute on client nodes

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/748


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3328) .NET: cacheConfiguration.AffinityFunction

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3328:
--

 Summary: .NET: cacheConfiguration.AffinityFunction
 Key: IGNITE-3328
 URL: https://issues.apache.org/jira/browse/IGNITE-3328
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 1.7


Allow custom AffinityFunction implementation in .NET



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request #803: IGNITE-3311 .NET: Include configuration schema in ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/803


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-3329) .NET: TestDeployNodeSingleton fails sporadically

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3329:
--

 Summary: .NET: TestDeployNodeSingleton fails sporadically
 Key: IGNITE-3329
 URL: https://issues.apache.org/jira/browse/IGNITE-3329
 Project: Ignite
  Issue Type: Test
  Components: platforms
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


{code}
Test(s) failed. System.NullReferenceException : Object reference not set to an 
instance of an object.
   at Apache.Ignite.Core.Tests.Services.ServicesTest.TestDeployNodeSingleton() 
in 
e:\BuildAgent\work\c6bd605b1bad5b0f\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Services\ServicesTest.cs:line
 158
{code]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request #809: IGNITE-3139 .NET: UTF-16 surrogate symbols are not...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

https://github.com/apache/ignite/pull/809

IGNITE-3139 .NET: UTF-16 surrogate symbols are not serialized properly



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ptupitsyn/ignite ignite-3139

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/809.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #809


commit 74c051230b906897babbcb6553af60e2af1b44a0
Author: Aleksei Scherbakov 
Date:   2016-05-12T12:47:01Z

IGNITE-3098: UTF-16 surrogate pairs are not properly serialized by 
BinaryMarshaller

commit 76717fd348a51ae597cb2bc99b9672994dde3264
Author: Denis Magda 
Date:   2016-05-13T05:24:37Z

IGNITE-3098: compilation fix

commit 99b8830e3af4a9dd596374fc21e5fb6d79ada083
Author: Denis Magda 
Date:   2016-05-13T05:40:02Z

Merge remote-tracking branch 'remotes/origin/ignite-1.6' into ignite-3098

commit d43b71c526d2ee0ac8a40bb52bbdbbaa8c595f13
Author: Denis Magda 
Date:   2016-05-16T08:08:11Z

IGNITE-3098: improvements

commit 9e167073fd51b78870b8f62e867518b1f540a080
Author: Denis Magda 
Date:   2016-05-16T08:11:10Z

Merge remote-tracking branch 'remotes/origin/ignite-1.6' into ignite-3098

commit 9c7824829da5f6994f4c302cc39f03ac897d6616
Author: Pavel Tupitsyn 
Date:   2016-05-16T09:16:59Z

IGNITE-3139 .Net: UTF-16 surrogate symbols are not serialized properly

commit d466a081249670feff843514453de85443b86251
Author: Pavel Tupitsyn 
Date:   2016-05-16T09:18:10Z

test added

commit 3c4e122d5e8c41d5ca051dd82e95e191bcd3dc9a
Author: Pavel Tupitsyn 
Date:   2016-05-16T09:29:13Z

wip

commit fa48e3dd6df615465c2447b5efa7ce9efdabdde5
Author: Pavel Tupitsyn 
Date:   2016-05-16T09:36:10Z

Refactor string writes

commit 4196e1ff0fd3536027add755ad51b796afc47d79
Author: Pavel Tupitsyn 
Date:   2016-05-16T09:55:54Z

wip

commit 42d892816507280d3a5897210221591bc88f6430
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:00:28Z

wip

commit d1d52b3940bb1227787833360c8acb788763
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:08:58Z

wip

commit 3f9326e9824f1c6573ac02d372645185de685d8b
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:13:24Z

wip

commit da494d0a43284ca2d6d2594f7d58145c017e05f7
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:44:40Z

wip

commit 91d079a4b1625ec70c1159656bd2a0839f815b93
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:49:19Z

Fix length calculation - tests work

commit e6980ac51a886dae54be9a5e1f0e61893d310360
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:53:13Z

wip

commit d879325317bcfee02aca5d72bea23c69bcd74899
Author: Pavel Tupitsyn 
Date:   2016-05-16T10:56:37Z

wip

commit 162a1bedd9b89c3b3e40acc456aa7a79e8a64771
Author: Pavel Tupitsyn 
Date:   2016-05-16T11:12:20Z

wip cleanup

commit cbb7ecb323b3e87432c74e082f92a30531c9c7fb
Author: Pavel Tupitsyn 
Date:   2016-05-16T11:14:09Z

wip tests

commit f606c71466f388aed1cdaf407ec278f5f0cf21eb
Author: Pavel Tupitsyn 
Date:   2016-05-16T11:23:26Z

wip

commit d6abe080978eea34b6067971ca557453a245c6dc
Author: Pavel Tupitsyn 
Date:   2016-05-16T11:26:23Z

wip

commit 0dc1f9d1343c4bee96f28b2223723ebaa4a4a3d1
Author: Pavel Tupitsyn 
Date:   2016-05-16T11:54:19Z

wip

commit 5d1960cca587efd8a1cce72a75404d5c9bd39dab
Author: Pavel Tupitsyn 
Date:   2016-05-16T12:21:23Z

wip

commit af3d2ebfe28d1263240ba4b342cbc15dab3a2565
Author: Pavel Tupitsyn 
Date:   2016-05-16T12:26:01Z

wip

commit d97813a72cd6ba7607b1feb387b546ccfd00a117
Author: Pavel Tupitsyn 
Date:   2016-05-16T12:33:40Z

wip

commit efc80b43b7cc69ed17cbc225adb654299634ea1b
Author: Pavel Tupitsyn 
Date:   2016-05-16T12:55:49Z

wip

commit 5ff788dbe3b6c5bb1559fb261d3141bdfb904ebf
Author: Pavel Tupitsyn 
Date:   2016-05-16T13:08:14Z

Finally, test works, damn it

commit 2439812546ea14f5a191881b5c59ccaed4af123a
Author: Pavel Tupitsyn 
Date:   2016-05-16T13:11:42Z

Check special strings with Java

commit 53999e33c771caad5cfccad386f62dcea6af53a4
Author: Pavel Tupitsyn 
Date:   2016-05-16T13:13:44Z

wip

commit 1407152178c29e43efbb382d585f4d80fd5df264
Author: Pavel Tupitsyn 
Date:   2016-05-16T13:30:09Z

failure test added




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: IGNITE-3293 AWS bootstrap scripts patch for Ignite-Cassandra

[Alexey Kuznetsov]

I'm reviewed this issue. Comments added to ticket.

On Mon, Jun 13, 2016 at 10:42 PM, Igor Rudyak  wrote:

> Could somebody please look at the pull request
> https://github.com/apache/ignite/pull/794 related to
> https://issues.apache.org/jira/browse/IGNITE-3293 ticket.
>
> It's fixes rather important thing for AWS Ignite/Cassandra clusters
> bootstrap scripts.
>
> Thanks,
> Igor Rudyak
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-3330) CPP: Implement Cache::Invoke method.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3330:
---

 Summary: CPP: Implement Cache::Invoke method.
 Key: IGNITE-3330
 URL: https://issues.apache.org/jira/browse/IGNITE-3330
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.7


Implement {{Cache::Invoke}} method for the Ignite C++.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request #809: IGNITE-3139 .NET: UTF-16 surrogate symbols are not...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/809


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #810: Ignite 3184

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

https://github.com/apache/ignite/pull/810

Ignite 3184



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/iveselovskiy/ignite ignite-3184

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/810.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #810






---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---