Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-2527 Renames the schematic package to org.modeshape and removes all ISPN related code.

    • -113
    • +0
    ./AddValueIfAbsentOperation.java
  1. … 303 more files in changeset.
MODE-2437 Removed Infinispan test-jar dependencies and reduced as much as possible the regular ISPN API dependencies throughout the code.

  1. … 49 more files in changeset.
MODE-2066 Migrated to Infinispan 6.0.1 and JGroups 3.4.1. Beside the changes involving package migrations and API changes, because the BDB and JDBM cachestore have not been ported to 6.x yet, all references (only unit tests) to those cache stores were removed and replaced with LevelDB. The old FileCacheStore has been discontinued and therefore replaced with SingleFileStore.

  1. … 88 more files in changeset.
MODE-2148 Added checkstyle to our build, and corrected numerous potential problems or issues in the code. Also removed lots of meaningless JavaDoc

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

    • -17
    • +10
    ./AddValueIfAbsentOperation.java
  1. … 107 more files in changeset.
MODE-1745 Removed code that was commented out

MODE-1745 Corrections to Schematic's state transfer

Several issues related to state-transfer were identified and corrected within Schematic's DeltaAware implementation. These primarily dealt with using diff-based deltas when using Infinispan 5.2.0 (tested with Beta6 and later), the implementations of the two deltas (and related classes), and how merges are made, and removal of the NullDelta class.

With these changes, the test projects in MODE-1745 and MODE-1746 work better. There still are problems with state transfer during repository initialization. See MODE-1745 for details.

  1. … 7 more files in changeset.
MODE-1733 Additional corrections and changes, per the code review

  1. … 2 more files in changeset.
MODE-1733 Changed SchematicEntryDelta behavior

The original problem is that the delta is being merged to a null entry

reference when the entry has been evicted from the cache. The correct

behavior would be to look up the persisted entry and merge the detal

with that. Infinispan is not behaving correctly.

This problem appears to be very similar to ISPN-2095, though we're

not using AtomicHashMap but have our own DeltaAware implementation

(called SchematicEntry).

The fix for ISPN-2095 involved changing AtomicHashMapProxy to use a

specific "DELTA_WRITE" cache flag that was added in Infinispan

5.1.6.FINAL. That means we don't have access to the fix in 5.1.2.FINAL,

so we need to provide an alternative solution for pre-5.1.6.FINAL releases.

The CacheContext now attempts to set that flag only when we're using

Infinispan 5.1.6 or later (e.g., if we can find the "DELTA_WRITE" flag),

but the changes still don't seem to correct the behavior with

Infinispan 5.1.2.FINAL, 5.1.6.FINAL or 5.1.8.Final. Even if it

worked on 5.1.6 or later, we would still have the issue when using

5.1.2.FINAL (which is all AS7.1.1 installations).

We need a solution that works with Infinispan 5.1.2 or later.

One option was to make the SchematicEntryLiteral instances no longer

implement DeltaAware. However, that means that we'd be changing the

class for the values we're storing in Infinispan. It also means that

we could not use DeltaAware in some environments (for example, when

we're using newer versions of Infinispan).

A better approach taken with this commit is to use different Delta

implementations depending upon the configuration. With this commit

there are two Delta implementations: one that works like before by

recording the Operations used to manipulate the documents, and a new

one that simply contains the whole document.

The benefit of this approach is that we can then choose which Delta

implementation we use based upon the Infinispan configuration and version:

- In local (non-clustered) caches, we actually don't need to compute a

Delta. In this case we can use the whole document Delta and a

different DocumentEditor that doesn't actually create any operations.

- In clustered caches that do not use eviction, we can use the

diff-based Delta with an editor that does calculate the change

operations. These Delta instances are correctly merged.

- In clustered caches that do use eviction, we need to use the

whole-document Delta. And since this delta doesn't record operations,

we could use a DocumentEditor that doesn't actually create operations.

All tests (including several new clustering tests) pass with these

changes. Additionally, the clustering test attached by the reporter

to MODE-1733 also passes with these changes, when using either

Infinispan 5.1.2.FINAL or 5.1.8.Final.

  1. … 14 more files in changeset.
MODE-1703 Corrected serialization of Schematic deltas

Array objects were not being serialized/deserialized properly

within the delta's operation instances (e.g., PutOperation).

Normally, all SchematicEntry (e.g., Documents containing values

such as Arrays and other Documents) are serialized using BSON, and

this works correctly in the non-clustered case. However, in the

clustered case, the changes made to one Document are recorded to

create a SchematicEntryDelta that is shipped across the Infinispan

cluster. (This way we can ship only the changes to the

SchematicEntry rather than the whole document.) Thus the problem

only manifest itself in clustered configurations.

The actual problem stemmed from the fact that an

SchematicEntryDelta and its Operation objects are all

externalizable (with custom Externalizers). The Operation objects

can contain individual values, Document or Array objects. These are

also externalizable, but there was a single DocumentExternalizer

for both Document and Array objects and the DocumentExternalizer

wrote/read both to/from BSON.

However, the BSON format (which is simply a binary representation

of JSON documents, with a few extra value types) is only valid for

Documents; a standalone Array cannot be written in BSON format.

The solution was to use the DocumentExternalizer for Documents, but

a new ArrayExternalizer for Arrays. This ArrayExternalizer still

uses BSON, but it uses a subset of the BSON representation to

serialize Array objects. But, it does work well and fixes the

problem.

Quite a few new tests were added to verify that the various

operations with various parameters are indeed externalizable. The

tests don't cover all the permuations, but they do attempt to cover

the different kinds of operations with documents and arrays.

To make the Operation objects easily testable, equals and hashCode

methods were added to all the Operation subclasses. Additionally,

all of the externalizers were manually reviewed for asymmetric read

and write methods (e.g, writing an object to the ObjectOutputStream

but reading an integer from the ObjectInputStream), and several

asymmetries were found in the Externalizers for BSON value types

that ModeShape doesn't currently use, and these asymmetries were

corrected.

All unit and integration tests pass with these changes.

  1. … 14 more files in changeset.
MODE-1703 Corrected serialization of Schematic deltas

Array objects were not being serialized/deserialized properly

within the delta's operation instances (e.g., PutOperation).

Normally, all SchematicEntry (e.g., Documents containing values

such as Arrays and other Documents) are serialized using BSON, and

this works correctly in the non-clustered case. However, in the

clustered case, the changes made to one Document are recorded to

create a SchematicEntryDelta that is shipped across the Infinispan

cluster. (This way we can ship only the changes to the

SchematicEntry rather than the whole document.) Thus the problem

only manifest itself in clustered configurations.

The actual problem stemmed from the fact that an

SchematicEntryDelta and its Operation objects are all

externalizable (with custom Externalizers). The Operation objects

can contain individual values, Document or Array objects. These are

also externalizable, but there was a single DocumentExternalizer

for both Document and Array objects and the DocumentExternalizer

wrote/read both to/from BSON.

However, the BSON format (which is simply a binary representation

of JSON documents, with a few extra value types) is only valid for

Documents; a standalone Array cannot be written in BSON format.

The solution was to use the DocumentExternalizer for Documents, but

a new ArrayExternalizer for Arrays. This ArrayExternalizer still

uses BSON, but it uses a subset of the BSON representation to

serialize Array objects. But, it does work well and fixes the

problem.

Quite a few new tests were added to verify that the various

operations with various parameters are indeed externalizable. The

tests don't cover all the permuations, but they do attempt to cover

the different kinds of operations with documents and arrays.

To make the Operation objects easily testable, equals and hashCode

methods were added to all the Operation subclasses. Additionally,

all of the externalizers were manually reviewed for asymmetric read

and write methods (e.g, writing an object to the ObjectOutputStream

but reading an integer from the ObjectInputStream), and several

asymmetries were found in the Externalizers for BSON value types

that ModeShape doesn't currently use, and these asymmetries were

corrected.

All unit and integration tests pass with these changes.

  1. … 14 more files in changeset.
MODE-1703 fixed problems with invalid deserialization of Path and AddValueOperation, still doesn't solve problem as we start to get NullPointerException in ArrayOperation.mutableParent

  1. … 1 more file in changeset.
MODE-1703 fixed problems with invalid deserialization of Path and AddValueOperation, still doesn't solve problem as we start to get NullPointerException in ArrayOperation.mutableParent

  1. … 1 more file in changeset.
MODE-1521 Adde support for 'put-if-absent' behavior in the Schematic Editor/Changes functionality

Using the Editor framework to modify a document didn't always work correctly when used in a heavily

concurrent way, because when some of the 'put' operations (to use an empty document) were applied they'd

forcibly override any existing value created since the changes were recorded. Adding a 'put-if-absent'

operation makes the changes more correctly match the semantics.

All unit tests and integration tests succeed with these changes.

    • -0
    • +126
    ./PutIfAbsentOperation.java
  1. … 7 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. … 21 more files in changeset.
MODE-1289 Added more tests and corrected the Schematic's Operation framework

  1. … 17 more files in changeset.
MODE-1289 Implemented versioning and import/export

Created the JcrVersionManager that contained most of the logic from the legacy 'modeshape-jcr' module.

Much of that logic could be moved as is, but any of it that directly used the graph API or batches

had to be changed to use the new CachedNode API. The latter should be significantly more efficient

than the former, since the former was forcing at least one refresh (and sometimes multiple refreshes)

of the version history, while the CachedNode API doesn't require any refreshes.

Added support for importing and exporting repository content using system and document views, as

defined by the specification. Migrated the unit tests for the import/export functionality.

Note that unit tests for the versioning have not yet been migrated, but will be in forthcoming commits.

    • -43
    • +52
    ./AddValueIfAbsentOperation.java
  1. … 94 more files in changeset.
MODE-1289 New approach for storing/caching JCR content

This is the first commit to start the 3.0 effort, which involves a major change to how

the JCR layer stores and caches information. The new approach is based upon Infinispan and uses

Infinispan's cache loaders for persistence, and JSON-like documents (that are in-memory

structures not needing to parsed/written) are used to store information for each node.

There are several new Maven modules:

- modeshape-jcr-redux

- modeshape-schematic

The 'modeshape-jcr-redux' module will eventually replace the 'modeshape-jcr' module once

the implementation is far-enough along. And the 'modeshape-schematic' module will likely

move into the Infinispan project, so that needs to remain separate.

Although it may seem strange and unkempt to have the new JCR implementation in a new module,

doing so means that we can continue to rebase from 'master' (and the 2.7 work) for at least

some time. When the new module becomes complete enough, we'll move it and replace the

existing 'modeshape-jcr' module. It's also convenient to have both the old and new implementations

around in the same codebase.

The build was changed to focus upon the (few) modules that are oriented around the new

implementation. So the following can be used to build the newer codebase:

mvn clean install

However, the build has a new Maven profile called "legacy" that can be used to build the

old modules. We kept this to make sure that any rebasing can be compiled and verified.

For example, to build everyhing, including the new modules and the 2.x-style modules,

use the following command:

mvn clean install -Plegacy

As the newer 'modeshape-jcr-redux' progresses and other modules (e.g., sequencers, web,

jboss, text extractors) are converted to use the new module, they should be moved

from the 'legacy' profile into the main set of modules in the top-level 'pom.xml'

    • -0
    • +94
    ./AddValueIfAbsentOperation.java
    • -0
    • +120
    ./AddValueOperation.java
    • -0
    • +59
    ./ArrayOperation.java
    • -0
    • +100
    ./ClearOperation.java
    • -0
    • +28
    ./DocumentObserver.java
    • -0
    • +107
    ./PutOperation.java
    • -0
    • +129
    ./RemoveAllValuesOperation.java
    • -0
    • +100
    ./RemoveAtIndexOperation.java
    • -0
    • +100
    ./RemoveOperation.java
    • -0
    • +101
    ./RemoveValueOperation.java
    • -0
    • +106
    ./RetainAllValuesOperation.java
    • -0
    • +107
    ./SetValueOperation.java
  1. … 434 more files in changeset.