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.

  1. … 313 more files in changeset.
Corrected compiler and JavaDoc warnings

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

  1. … 120 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-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.

  1. … 18 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'

  1. … 447 more files in changeset.