ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-1818 Repository configuration can now dictate garbage collection options.

The garbage collection options can now be specified in the repository

configuration. Each repository registers its own garbage collection

processes with a named thread pool, and these processes are stopped

when the repository is shut down.

MODE-1818 Repository configuration can now dictate garbage collection options.

The garbage collection options can now be specified in the repository

configuration. Each repository registers its own garbage collection

processes with a named thread pool, and these processes are stopped

when the repository is shut down.

Merge branch 'MODE-1753' of git://github.com/jstansel/modeshape into jstansel-MODE-1753

MODE-1753 Removed "pardon our dust" from the 3.0 beta days

The top of the README.md file contained out-dated information from when

the 3.0 work had first moved to the master branch. Zapped it.

MODE-1753 Merge two README files into one

Simple-minded merge:

* copy the information from the README_COMMITTERS.txt file and insert

into appropriate place in the README.md file

* remove the README_COMMITTERS.txt file

MODE-1796 Changed the InfinispanBinaryStore garbage collection logic

The RemoteCache or a RemoteCacheStore do not support map-reduce,

so we have to process the contents in a different way.

MODE-1817 Corrected logic of concurrent removals

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).

MODE-1817 Corrected logic of concurrent removals

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).

MODE-1809 Corrected the processing of set queries, including unions

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.

MODE-1809 Corrected the processing of set queries, including unions

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.

MODE-1816 REST v2 responses base property representations on number of 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.

MODE-1816 REST v2 responses base property representations on number of 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.

MODE-1813 - Updated CDI test with a test-case that allow replication of the issue. Also, added the explicit dependency as fix.

MODE-1813 - Implemeted an Arquillian based test using CDI and various deployment units.

MODE-1813 - Updated CDI test with a test-case that allow replication of the issue. Also, added the explicit dependency as fix.

MODE-1813 - Implemeted an Arquillian based test using CDI and various deployment units.

MODE-1804 - Corrected the schema and the Hibernate Search parameters for the jgroups-slave backend.

MODE-1804 - Corrected the schema and the Hibernate Search parameters for the jgroups-slave backend.

MODE-1816 The jcr:mixinTypes properties should not need to be first in 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.

    • -0
    • +7
    /web/modeshape-web-jcr-rest-war/pom.xml
MODE-1816 The jcr:mixinTypes properties should not need to be first in 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.

    • -0
    • +7
    /web/modeshape-web-jcr-rest-war/pom.xml
MODE-1807 - Fixed the validation of residual child definitions

MODE-1807 - Fixed the validation of residual child definitions

MODE-1811 - Fixed the InfinispanBinaryStore not being able to load a class from modeshape-jcr, by making that class available in the AS 7.1.1 kit to the org.infinispan.main module.

MODE-1811 - Fixed the InfinispanBinaryStore not being able to load a class from modeshape-jcr, by making that class available in the AS 7.1.1 kit to the org.infinispan.main module.

MODE-1805 Minor cleanup of code per code review

MODE-1805 Minor cleanup of code per code review

MODE-1807 - Changed the order of steps in the node validation algorithm and updated the test case that caused this issue

MODE-1807 - Changed the order of steps in the node validation algorithm and updated the test case that caused this issue

    • -0
    • +22
    /modeshape-jcr/src/test/resources/cnd/orc.cnd
MODE-1805 Query system can be disabled in AS7 kit

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.

  1. … 6 more files in changeset.
MODE-1805 Query system can be disabled in AS7 kit

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.

  1. … 6 more files in changeset.