Re: JCache dependency

2016-03-29 Thread Dmitriy Setrakyan
We will switch the Ignite JAR to the 1.0-alpha-1 version from Geronimo, but I am still very confused. I do not understand why we need to check any TCK compliance when creating a JAR for the JSR107 spec. The TCK compliance should be checked against an implementation, not a spec. Is there any

Re: JCache dependency

2016-03-29 Thread Romain Manni-Bucau
ok, let me try to make it clearer (and don't hesitate to shout if still not ;)): TCK are not only @Test but also some bianary validations (aka sigtest or signature tests) the spec jars need to pass. It basically checks you respect the spec signature for the supported java version of the spec. Not

Re: Controlling type of object inserted in IgniteCache

2016-03-29 Thread Dmitriy Setrakyan
On Tue, Mar 29, 2016 at 3:49 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > How about adding setTypeNames() configuration property that will be similar > to setTypes(), but for binary objects? > Agree. Sounds like it will solve the problem, no? > > -Val > > On Tue, Mar 29,

Re: JCache dependency

2016-03-29 Thread Dmitriy Setrakyan
I just mention to mention that Apache Ignite passes JCache TCK with flying colors :) We have it integrated into our build routine and verify it using our CI tests. In addition, it was verified by one of the JCache spec leads, Greg Luck, who confirmed that Ignite complies with the spec. Given the

[jira] [Created] (IGNITE-2904) IgniteStream API Implementation

2016-03-29 Thread Roman Shtykh (JIRA)
Roman Shtykh created IGNITE-2904: Summary: IgniteStream API Implementation Key: IGNITE-2904 URL: https://issues.apache.org/jira/browse/IGNITE-2904 Project: Ignite Issue Type: New Feature

[GitHub] ignite pull request: IGNITE-2900: Fixed exception on type update.

2016-03-29 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/581 --- 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

[GitHub] ignite pull request: IGNITE-2550 .NET: Simplify examples configura...

2016-03-29 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/570 --- 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

Controlling type of object inserted in IgniteCache

2016-03-29 Thread Denis Magda
Igniters, In some cases there is necessity to control a type of object that is being inserted into a cache. Presently this kind of check is accomplished at compile time only relying on Java Generics. However it doesn't prevent us from connecting to a cluster using a non-generic instance of a

[jira] [Created] (IGNITE-2905) Window processing support for IgniteStream

2016-03-29 Thread Roman Shtykh (JIRA)
Roman Shtykh created IGNITE-2905: Summary: Window processing support for IgniteStream Key: IGNITE-2905 URL: https://issues.apache.org/jira/browse/IGNITE-2905 Project: Ignite Issue Type:

[GitHub] ignite pull request: IGNITE-2902: IgniteError now implements std::...

2016-03-29 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/582 --- 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

[GitHub] ignite pull request: Professional 7.5.11

2016-03-29 Thread avinogradovgg
GitHub user avinogradovgg opened a pull request: https://github.com/apache/ignite/pull/585 Professional 7.5.11 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite gridgain-7.5.11 Alternatively you can review

[jira] [Created] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)

2016-03-29 Thread Krome Plasma (JIRA)
Krome Plasma created IGNITE-2906: Summary: Embedded / child element types indexing/queryfields (non-flat) Key: IGNITE-2906 URL: https://issues.apache.org/jira/browse/IGNITE-2906 Project: Ignite

Re: API for asynchronous execution.

2016-03-29 Thread Vladimir Ozerov
We already had discussion about it several months ago. Normal practice is to allow user specify thread pool where he would like to execute the callback. This is how things work in JDK CompletableFutures and Hazelcast futures, and this is the most flexible approach. On Tue, Mar 29, 2016 at 2:23

[jira] [Created] (IGNITE-2907) GridServiceNotFoundException is not descriptive

2016-03-29 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-2907: -- Summary: GridServiceNotFoundException is not descriptive Key: IGNITE-2907 URL: https://issues.apache.org/jira/browse/IGNITE-2907 Project: Ignite Issue

[jira] [Created] (IGNITE-2908) .NET: Missing IgniteConfiguration properties

2016-03-29 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-2908: -- Summary: .NET: Missing IgniteConfiguration properties Key: IGNITE-2908 URL: https://issues.apache.org/jira/browse/IGNITE-2908 Project: Ignite Issue

Re: API for asynchronous execution.

2016-03-29 Thread Vladimir Ozerov
Nick, I hardly can image why user would like to have async entry processor provided that we already have IgniteCache.withAsync(). Moreover, usually this method is invoked while holding lock on entry, so it doesn't seem to be a valid use case (plus remember about unwrap() method). Though, may be I

[jira] [Created] (IGNITE-2909) Checking cache object type in runtime

2016-03-29 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-2909: --- Summary: Checking cache object type in runtime Key: IGNITE-2909 URL: https://issues.apache.org/jira/browse/IGNITE-2909 Project: Ignite Issue Type: Improvement