ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-1386 Corrected build script to handle recent changes to JIRA

MODE-1386 Corrected build script to handle recent changes to JIRA

'Release: update versions for modeshape-3.0.0.Alpha1'

    • -1
    • +1
    /modeshape-assembly-descriptors/pom.xml
  1. … 29 more files in changeset.
MODE-1326 Fixed Oracle DDL exception when parsing CREATE UNIQUE INDEX statement

MODE-1326 Fixed Oracle DDL exception when parsing CREATE UNIQUE INDEX statements

The fix was to implement minimal support for unique index in the Oracle parser and to make sure that only "legal" token are delegated to the standard parser.

MODE-1386 Updated Maven assemblies, corrected dependencies, and added examples

The Maven assemblies were corrected (a bit; still work to do to create usable distributions),

but several dependencies were removed and two examples were added to the codebase (but not to

the build yet).

    • -0
    • +52
    /demos/embedded-repo/pom.xml
    • -0
    • +14
    /demos/embedded-repo/src/main/resources/my-repository-config.json
    • -0
    • +136
    /demos/sequencers/pom.xml
    • -0
    • +56
    /demos/sequencers/src/main/assembly/basic.xml
    • -0
    • +1
    /demos/sequencers/src/main/config/run.cmd
    • -0
    • +3
    /demos/sequencers/src/main/config/run.sh
    • binary
    /demos/sequencers/src/main/resources/caution.gif
  1. … 46 more files in changeset.
MODE-1387: Removed extra folder under modules and removed unneeded depencies from the org.modeshape module

MODE-1384 Changed JBoss AS7 kit assembly to use project version variable

Previously, the '3.0-SNAPSHOT' was hardcoded. Plus, some of the Maven modules were

referencing 'modeshape-jcr-redux', which was just replaced by 'modeshape-jcr'.

Even with a clean Maven repository, the build works well.

Temporarily removed the 'modeshape-unit-test' module

The module was temporarily removed from the build, since it requires the 'modeshape-jdbc-local' module

that has not yet been included in the build (since it depends on queries working).

Fixed sequencer dependencies after -redux renaming to -jcr

MODE-1377 Fixed webdav repository path parsing with trailing slash.

- changed request path parsing so that multiple empty '/' characters are collapsed into one.

- updated pom.xml so that log4j dependency is runtime (this is not ideal, but until slf4j dependencies are changed, this should be there)

    • -2
    • +8
    /web/modeshape-web-jcr-webdav-war/pom.xml
MODE-1377 Fixed webdav repository path parsing with trailing slash.

- changed request path parsing so that multiple empty '/' characters are collapsed into one.

- updated pom.xml so that log4j dependency is runtime (this is not ideal, but until slf4j dependencies are changed, this should be there)

    • -2
    • +8
    /web/modeshape-web-jcr-webdav-war/pom.xml
MODE-1381: Removed unneeded dependencies from modules and removed extraneous interface from services.

MODE-1368 Removed all legacy modules no longer needed in 3.x

ModeShape 3.x will not need a number of the 2.x modules. In particular:

- since 3.x will only have an AS7 kit, the AS5 or AS6 artifacts were removed

- all the connectors were removed, since they're no longer used

- the connector benchmark tests module was removed, replaced by our new

performance test suite

- the JPA DDL generator utility has been removed

- the 'modeshape-graph', 'modeshape-repository', 'modeshape-search-lucene'

and 'modeshape-clustering' modules have all been removed, since the new

'modeshape-jcr' module no longer uses them

- the DocBook modules were removed and are replaced by the Confluence space

- the two JDBC modules were moved out of the 'utils' directory to top-level modules

The build still works, but not all components have been included in the build.

This is because the query functionality doesn't yet work, so quite a few web

and JDBC driver modules all depend on this.

The assembly profile has not yet been changed or corrected.

    • -61
    • +0
    /deploy/jbossas/assembly/kit-as6.xml
    • -11
    • +0
    /deploy/jbossas/kit/conf/jboss-modeshape-log4j.xml
  1. … 3639 more files in changeset.
MODE-1381: Updated POM

MODE-1381: Added JcrEngine as a service

  1. … 3 more files in changeset.
MODE-1380 Improve NodeTypeManager.registerNodeType methods

Make the ModeShape-specific NodeTypeManager.registerNodeTypes(...) methods more like the standard javax.jcr.nodetype.NodeTypeManager.registerNodeTypes(...) method. In particular, update the JavaDoc and change the return type from void to NodeTypeIterator.

MODE-1342 Minor corrections of warnings and JavaDoc errors.

MODE-1342 Ported xsd sequencer to 3.x

    • -0
    • +100
    /sequencers/modeshape-sequencer-sramp/pom.xml
    • -0
    • +177
    /sequencers/modeshape-sequencer-xsd/pom.xml
  1. … 26 more files in changeset.
MODE-1339 Ported text sequencer to 3.x

    • -0
    • +144
    /sequencers/modeshape-sequencer-text/pom.xml
  1. … 14 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.

  1. … 13 more files in changeset.
MODE-1339 Enhanced the types of properties which can be set on components.

- it should now be possible to set arrays, collection instances, maps and nested beans.

- refactored the component creation code in RepositoryConfiguration

MODE-1373 Fixed mismatch between ms office cnd and code

MODE-1374 Corrected node type init errors in concurrent env

The JcrNodeDefinition is intended to be immutable and thread-safe, and although

it is publicly immutable, internally it delays loading the references to the

required primary types until needed. The 'ensureRequiredPrimaryTypesLoaded()' method

is what lazily initializes the references, and this method is properly called in

the right spots within JcrNodeDefinition. However, in a highly-concurrent environment

a node type definition may be needed by multiple threads, and this can result

in this method being called concurrently. Unfortunately this method is not thread-safe,

and can cause a NullPointerException when used concurrently.

Unlike the fix in the 2.x codebase, this change removes the cached JcrNodeType references

(both the array and the map keyed by Name) from JcrNodeDefinition. This simplifies the

JcrNodeDefinition class by making it fully immutable (not just publicly immutable).

It also ensures that when node types are updated, they are accurately reflected in

all child node definitions.

With this change, all unit and integration tests pass.

Merge branch 'MODE-1337' of https://github.com/hchiorean/modeshape into hchiorean-MODE-1337

MODE-1374 Corrected node type init errors in concurrent env

The JcrNodeDefinition is intended to be immutable and thread-safe, and although

it is publicly immutable, internally it delays loading the references to the

required primary types until needed. The 'ensureRequiredPrimaryTypesLoaded()' method

is what lazily initializes the references, and this method is properly called in

the right spots within JcrNodeDefinition. However, in a highly-concurrent environment

a node type definition may be needed by multiple threads, and this can result

in this method being called concurrently. Unfortunately this method is not thread-safe,

and can cause a NullPointerException when used concurrently.

The 'ensureRequiredPrimaryTypesLoaded()' method just iterates through the names of the

required primary types (which were set in the constructor), and looks up the JcrNodeType

instances for each primary type name. It then creates an immutable map to quickly find

the JcrNodeType instances given the primary type name. Finally, it stores the map

and the names, and when the array of JcrNodeType instances and map are available

(non-null), it merely uses the values. But the creation of the JcrNodeType array and

map keyed by name are not concurrent or atomic. In fact, a non-empty array is created

(but not initialized, so it contains null references) and _immediately set_ on one of the

JcrNodeDefinition fields, so when the method is called by other threads it is as if

the JcrNodeType array is ready to be used. But the original thread hasn't yet set

the JcrNodeType references in the array, so any other thread that uses the array

gets a null reference instead, and using that causes the NullPointerException.

The fix is relatively simple: ensure that the 'requiredPrimaryTypes' array of JcrNodeType

and 'requiredPrimaryTypesByName' map are set in a synchronized way, ensuring they

are only set to non-null with an array (or map) that are fully and correctly populated.

This could be done by simply synchronizing the entire 'ensureRequiredPrimaryTypesLoaded()'

method, but the method calls out to the RepositoryNodeTypeManager. And while the RNTM

doesn't currently (directly or indirectly) result in a call to 'ensureRequiredPrimaryTypesLoaded()',

it's possible it might in the future. Therefore, we can simply create and fully-populate

the array and map outside of the synchronization block, and only synchronize upon setting

it (of course checking before we set it whether another thread snuck in and set it

while we waited for the lock). So it is effectively the same as synchronizing the method

(which the reporter says fixes the problem), but does it with smaller lock scope.

With this change, all unit and integration tests pass.

MODE-1374 Corrected node type init errors in concurrent env

The JcrNodeDefinition is intended to be immutable and thread-safe, and although

it is publicly immutable, internally it delays loading the references to the

required primary types until needed. The 'ensureRequiredPrimaryTypesLoaded()' method

is what lazily initializes the references, and this method is properly called in

the right spots within JcrNodeDefinition. However, in a highly-concurrent environment

a node type definition may be needed by multiple threads, and this can result

in this method being called concurrently. Unfortunately this method is not thread-safe,

and can cause a NullPointerException when used concurrently.

The 'ensureRequiredPrimaryTypesLoaded()' method just iterates through the names of the

required primary types (which were set in the constructor), and looks up the JcrNodeType

instances for each primary type name. It then creates an immutable map to quickly find

the JcrNodeType instances given the primary type name. Finally, it stores the map

and the names, and when the array of JcrNodeType instances and map are available

(non-null), it merely uses the values. But the creation of the JcrNodeType array and

map keyed by name are not concurrent or atomic. In fact, a non-empty array is created

(but not initialized, so it contains null references) and _immediately set_ on one of the

JcrNodeDefinition fields, so when the method is called by other threads it is as if

the JcrNodeType array is ready to be used. But the original thread hasn't yet set

the JcrNodeType references in the array, so any other thread that uses the array

gets a null reference instead, and using that causes the NullPointerException.

The fix is relatively simple: ensure that the 'requiredPrimaryTypes' array of JcrNodeType

and 'requiredPrimaryTypesByName' map are set in a synchronized way, ensuring they

are only set to non-null with an array (or map) that are fully and correctly populated.

This could be done by simply synchronizing the entire 'ensureRequiredPrimaryTypesLoaded()'

method, but the method calls out to the RepositoryNodeTypeManager. And while the RNTM

doesn't currently (directly or indirectly) result in a call to 'ensureRequiredPrimaryTypesLoaded()',

it's possible it might in the future. Therefore, we can simply create and fully-populate

the array and map outside of the synchronization block, and only synchronize upon setting

it (of course checking before we set it whether another thread snuck in and set it

while we waited for the lock). So it is effectively the same as synchronizing the method

(which the reporter says fixes the problem), but does it with smaller lock scope.

With this change, all unit and integration tests pass.

MODE-1373 Moved code which validates sequenced nodes to AbstractSequencerTest

MODE-1337 Cleaned up maven compiler settings

    • -14
    • +0
    /modeshape-performance-tests/pom.xml
MODE-1337 Ported Microsoft Office sequencer to 3.x

-fixed incompatibilities between cnd and code

-added unit tests

  1. … 15 more files in changeset.