modeshape-repository

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed components versions to 2.8.2.GA.

  1. … 67 more files in changeset.
MODE-1623 - Fixed the general setting of numeric properties which are not java.util.Long and in particular, the mode:isolationLevel property on the JPA source.

  1. … 2 more files in changeset.
MODE-1628 Fix storeTo method (configuration stored to xml contains not valid namespace "=")

MODE-1628 Fix storeTo method (configuration stored to xml contains not valid namespace "=")

'Release: update versions for modeshape-2.8.3.Final'

  1. … 70 more files in changeset.
'Release: update versions for modeshape-2.8.2.Final'

  1. … 70 more files in changeset.
'Release: update versions for modeshape-2.8.1.Final'

  1. … 70 more files in changeset.
MODE-1414 (related): promote version #'s in 2.5.x to 2.5.4.GA for BZ-786561 Roll up patch fro EDS_5.2_20120320

  1. … 68 more files in changeset.
Changed version to SNAPSHOT following release

  1. … 74 more files in changeset.
Changed the '2.8-SNAPSHOT' artifact version to '2.8.1.GA' for use in the product.

  1. … 74 more files in changeset.
'Release: update versions for modeshape-2.8.0.Final'

  1. … 70 more files in changeset.
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.

  1. … 3639 more files in changeset.
Changed version to 2.8-SNAPSHOT after releasing 2.7.0.Final

  1. … 73 more files in changeset.
'Release: update versions for modeshape-2.7.0.Final'

  1. … 76 more files in changeset.
MODE-1353: promote version #'s in 2.5.x to 2.5.3.GA for SOA-3656

  1. … 68 more files in changeset.
MODE-1305 Remove unused i18n methods

- also a small refactoring of the I18n class

  1. … 23 more files in changeset.
MODE-1305 Remove unused i18n methods

- also a small refactoring of the I18n class

  1. … 23 more files in changeset.
Changed versions to prepare for 2.7-SNAPSHOT development

  1. … 77 more files in changeset.
'Release: update versions for modeshape-2.6.0.Final'

  1. … 69 more files in changeset.
Changed version to 2.5.2.GA, in preparation for release.

  1. … 73 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.
'Release: update versions for modeshape-2.6.0.Beta2'

  1. … 69 more files in changeset.
MODE-1207 Added logging of sequencer problems

When sequencers have problems, nothing is done with them. This change now logs the errors, warnings and info problems.

  1. … 3 more files in changeset.
MODE-1207 Added logging of sequencer problems

When sequencers have problems, nothing is done with them. This change now logs the errors, warnings and info problems.

  1. … 3 more files in changeset.
'Release: update versions for modeshape-2.6.0.Beta1'

  1. … 69 more files in changeset.
Changed versions in POMs to '2.5.1.GA'

  1. … 65 more files in changeset.
Changed versions in POMs to '2.6-SNAPSHOT'

  1. … 65 more files in changeset.
Changed versions in POMs to '2.5.1-SNAPSHOT'

  1. … 65 more files in changeset.
MODE-497 Wrap system access, context class loader access, and reflection with doPrivileged

- Wrapped the method.invoke with doPrivileged.

- Also updated the exception handling in the changed code accordingly,

since the exceptions thrown by invoke method are wrapped in PrivilegedActionException

  1. … 5 more files in changeset.
MODE-1097 ModeShape JPA repository in JBoss AS takes a long time to initialize when number of nodes are large

I added a test case to reproduce the issue that Souvik noted. The gist of the issue seems to be that the reindexing that happens on engine startup requires a load of the entirety of the content graph. This exacerbates any existing performance issues with connectors. Here's the output from the test case for the FileSystemSource:

String built

Reloaded content for / in 00:00:00.001,981

Flushed existing content in 00:00:00.081,379

Reindexed content in 00:00:00.176,902

Initial Startup (creating schema): 00:00:03.065,375

Inserted 110 nodes: 00:00:16.462,787

Restarting engine...

Reloaded content for / in 00:00:00.000,456

Flushed existing content in 00:00:00.000,338

Reindexed content in 00:00:00.004,089

Subsequent Startup (no schema validation): 00:00:00.512,491

And the output for the same test with the JpaSource using an in-memory Derby database:

Reloaded content for / in 00:00:00.256,798

Flushed existing content in 00:00:00.152,776

Reloaded content for / in 00:00:00.057,895

Flushed existing content in 00:00:00.000,603

Reindexed content in 00:00:00.616,951

Initial Startup (creating schema): 00:00:07.848,034

Inserted nodes: 00:00:24.628,916

Restarting engine...

Reloaded content for / in 00:01:00.589,765

Flushed existing content in 00:00:00.000,395

Reloaded content for / in 00:00:00.083,478

Flushed existing content in 00:00:00.000,323

Reindexed content in 00:02:26.031,058

Subsequent Startup (no schema validation): 00:02:26.754,994

Even for an evenly-balanced 3x10 tree, there's a pretty profound difference in startup times. One short-term workaround would be to place large content in a file-based source when possible. Another low-impact possibility is to add a repository option that allows administrators to disable the reindexing entirely. This would be useful for repositories where content is not exposed externally (e.g., JpaStore, InfinispanStore) and the repository isn't clustered.

  1. … 9 more files in changeset.