ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
'Release: update versions for modeshape-3.1.2.Final'

    • -2
    • +2
    /boms/modeshape-bom-remote-client/pom.xml
  1. … 48 more files in changeset.
Updated the release notes

Updated the release notes for 3.1.2.Final

MODE-1818 Added garbage collection properties to AS7 schema and subsystem

Added the garbage collection configuration attributes to ModeShape's

XSD schema and subsystem, and added a unit test that verifies the

attributes are read correctly.

MODE-1818 Added garbage collection properties to AS7 schema and subsystem

Added the garbage collection configuration attributes to ModeShape's

XSD schema and subsystem, and added a unit test that verifies the

attributes are read correctly.

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