…of the issue. Also, added the explicit dependency as fix.
The RemoteCache or a RemoteCacheStore do not support map-reduce, so we have to process the contents in a different way.
Added a relatively-simple test case that replicated the exact exception using my hypothesized scenario. The test creates separate threads to concurrently remove a specific node and (after synchronizing on a CyclicBarrier) save their changes. Thus, the transient state of each Session does not see the uncommitted transient state of the other Session, but both sessions are saved roughly the same time (in different threads so different transactions are used). But since both need to acquire the lock on the same parent node, only one session will proceed first to successfully remove the node. When the second session proceeds, it no accepts the fact that the node was already removed and proceeds accordingly. (ACID transactions FTW!) The fix was pretty simple: be aware that attempting to remove an entry in the cache may return null if the entry does not exist (i.e., was recently removed).
The code was sorting and then removing duplicates in the tuples, but during pre-processing and planning, the internal structure of the tuples changed for certain kinds of queries (like unions with join) to add in node location information as additional columns. The removal of duplicates, however, was still incorrectly basing its access of the tuple values upon the smaller/earlier tuple structure. This cause various kinds of ClassCastExceptions. Added a test case that replicated the originally reported problem, which after the fix now passes.
…f values The response should base the field value for a given property based upon whether that JCR property is single-valued or multi-valued, not upon the number of values. If multi-valued, then the field value should be an array (even if there is just one item). Version 1 of the REST API already works this way, but the version 2 was changed. Note that it is still possible for property representations in requests to use a single value (rather than an array) when setting a multi-value to a single value, or the more conventional practice of using an array to set a multi-valued array. The latter is obviously required when setting the mutli-valued property to 0 or 2+ values. Several of the expected results were incorrect and have been changed.
… deployment units.
…for the jgroups-slave backend.
…n the JSON requests ModeShape should not expect that the "jcr:mixinTypes" property be before the other properties in the JSON request coming from REST clients. Some libraries will not allow clients to reliably choose the order. Added a test case to verify this now works.
…class from modeshape-jcr, by making that class available in the AS 7.1.1 kit to the org.infinispan.main module.
…hm and updated the test case that caused this issue
Added ability to completely disable the query system (including the generation/maintenance of indexes) in a repository in the AS7 subsystem. (The JSON repository configurations had this ability for some time, but it could not be controlled in AS7.) This adds a new "enable-queries" XML attribute on the "repository" element in the subsystem configuration. This attributes defaults to "true" and therefore is backward compatible. However, setting it to "false" will completely disable the indexing system, although any index storage and indexing configuration within a repository configuration will remain as-is; it will simply not be used. This means that the repository's indexes and query system can be disabled (perhaps on a temporary basis) and then re-enabled without having to completely reconfigure the index storage and indexing parameters. It was discovered that executing queries on a repository that had its query system disabled resulted in a NPE, because the running state did not have a RepositoryQueryManager instance. Rather than deal with all of the potential NPEs, a new specialization of the RepositoryQueryManager, called RepositoryDisabledQueryManager, was added and is instantiated within the running state when queries are disabled. This specialization essentially no-ops all of the operations. The result is that queries will return no results rather than throw an exception. Additional warning messages are logged when the indexes are indeed disabled, since this will rarely be done in production. Several new tests were added, including unit tests (in 'modeshape-jcr') and integration tests for the AS7 subsystem.
…itableConnector base class which now contains the flag and by moving the read-only checks to the FederatedDocumentStore.
… and implemented support for it in the base connector class. Also. updated the JSON schema to support it.
…t the information is persisted each time into the repository. This way there shouldn't be any problems if the shutdown of the repository isn't orderly.
…mentId() method, giving connector implementations an additional piece of information.
…d projection is created without an alias name or with an alias that ends in "/". Also, cleanup up a bit the code around preconfigured projections.
When importing XML, any XML namespaces should be used, even if the prefix for the XML namespace matches an existing namespace prefix. Per Section 11.1 of the JSR-283 specification, an existing JCR namespace should be used if its URL matches the XML namespace URI. If there is no existing JCR namespace matching the XML namespace URI, then the namespace should be registered using the XML namespace prefix if not already used or a generated prefix if the XML namespace prefix is already used. A new unit test case was added to verify the behavior.
…d to the default "minimum binary size" which controls what type of binaries are created.
…o the ones which are part of the JSON schema and which control the indexing rebuild behavior
… on startup feature.
…sitory level based on the "rebuildIndexesAtStartup" flag which contains 3 values: always, if_missing and never.
- a root node should not add itself as a parent (if it does, it exposes a StackOverflowError) - trailing slashes (/) in node ids should be removed when determining the file/parentFile - binary values (corresponding to jcr:content) shouldn't be queryable. If we want them to be queryable, we need to change the implementation to use ExternalBinaryValues.