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
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
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,
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
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 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 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
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
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 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 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
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
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
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
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
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
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
17 matches
Mail list logo