Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-2562 Fixes the parsing of backslash characters by the JsonReader

  1. … 11 more files in changeset.
MODE-2527 Renames the schematic package to org.modeshape and removes all ISPN related code.

    • -112
    • +0
    ./SystemPropertyFactoryTest.java
  1. … 311 more files in changeset.
MODE-2546 Implements locking at a repository level The repository in ModeShape 5 will be responsible to locking all changed nodes within a transaction and then making sure it unlocks them when the transaction completes. This is contrast to ModeShape 3 and 4 who relied on the ISPN to handle this aspect. This commit also removes all locking from ISPN in order to validate that the new approach work. One consequence of the new approach is that user-transactions crossing over multiple threads will not work anymore (see https://issues.jboss.org/browse/MODE-2495).

  1. … 42 more files in changeset.
MODE-2164 Added test to validate System.env() properties are substituted.

  1. … 1 more file in changeset.
MODE-2081 Changed the license for ModeShape code to ASL 2.0.

  1. … 119 more files in changeset.
MODE-1524 Changed Infinispan Externalizer implementations

The Infinispan Schematic Externalizers were changed from implementing AdvancedExternalizer

(which has some benefits but also issues in AS7.1) to Externalizer (which works in all environments

but isn't as efficient as AdvancedExternalizer).

One important fix: several of the externalized classes did not have a SerializeWith annotation.

  1. … 30 more files in changeset.
MODE-1375 Added support for system property variables in repository configuration JSON documents

The JSON Schema validation logic already looked for cases where a field value object does

not have the correct type expected in the JSON Schema; such situations were reported as

errors (just like the other errors). This was changed so that, in these situations, the

schema validator tries to convert the actual value to the expected type; if that doesn't work,

the error is reported as usual, but if it can be converted, a special "mismatched type" error

is reported instead and includes the actual value, the converted value, the actual type,

and the converted type. (To public users, this is merely just a regular error, though.)

Also added a method to create a copy of a Document using a supplied `ValueTransformer` instance,

which the copy logic uses to transform each of the values within the Document. This copy

logic returns the same Document instance (not a copy) if no values were transformed, but

returns a new Document object if at least one value was transformed.

Added another method to create a copy of a Document using the validation results, where

we look for all of the "mismatched type" errors and use the converted value in place of the

actual value. (This process includes nested documents and arrays.)

Then the RepositoryConfiguration constructors were modified to try to create a copy

of the supplied document using a SystemPropertyTransformer; if a new Document were created

(because variables were replaced), then the new Document is validated against the schema

and any "mismatched type" values are used to create a copy of the document with the

mismatched values converted to the expected values. The RepositoryConfiguration then

uses the new Document with converted values, and the user can continue to validate

the configuration using the existing "validate()" method. This is where any problems

with the system properties will show up to the user. For example, if a variable is

replaced with a system property that cannot be converted to the type expected by the

JSON Schema for that field, a normal validation error will be included in the validation

results.

In general, all this happens transparently to RepositoryConfiguration users.

    • -0
    • +116
    ./DocumentTransformerTest.java
    • -0
    • +115
    ./SystemPropertyFactoryTest.java
  1. … 26 more files in changeset.