ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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. … 54 more files in changeset.
Release: update versions for modeshape-3.0.0.Alpha1

    • -1
    • +1
    /modeshape-assembly-descriptors/pom.xml
  1. … 31 more files in changeset.
Removed System.out print statements in test case

Removed System.out print statements in test case

MODE-1418 Corrected certain queries with full-text search criteria

Certain JCR-SQL2 full-text search criteria were not being processed correctly.

Any f.t.s. criteria that specified a single property resulted in an incorrect

query plan.

Several changes were made to correct this behavior, and new unit tests were added.

MODE-1418 Corrected certain queries with full-text search criteria

Certain JCR-SQL2 full-text search criteria were not being processed correctly.

Any f.t.s. criteria that specified a single property resulted in an incorrect

query plan.

Several changes were made to correct this behavior, and new unit tests were added.

MODE-1418 Corrected certain queries with full-text search criteria

Certain JCR-SQL2 full-text search criteria were not being processed correctly.

Any f.t.s. criteria that specified a single property resulted in an incorrect

query plan.

Several changes were made to correct this behavior, and new unit tests were added.

MODE-1420 Fixed unwanted Hibernate Search warning messages

Hibernate Search's SearchConfiguration class defines a "isTransactionManagerExpected()"

method that dictates whether the warning messages should be logged (and that appears

to be the only way in which this method is used).

So far, ModeShape's org.modeshape.jcr.query.lucene.LuceneSearchConfiguration implementation

has returned 'true'. But this method should return 'false', since the re-indexing operations

are not performed within a transaction, so Hibernate Search shouldn't always expect a

transaction. Simply making this change makes the problematic log messages disappear, but

doesn't otherwise affect any functionality.

All unit and integration tests pass with these changes.

MODE-1397 Made JChannel configurable via the repository configuration

MODE-1417 Corrected versioning of files uploaded through REST client

The REST client library was versioning only the 'jcr:content' child node of an

'nt:file' node. While that's acceptable (since it's where the file's content is

actually stored), it's better if the 'nt:file' node itself was versioned.

This change simply changes the node where the 'mix:versionable' mixin is applied.

When a new 'nt:file' node is uploaded, that node is now made versionable instead

of the 'jcr:content' child. All existing content is still handled and versioned

correctly (as it was), and this change only affects content added using a

RESTful client that contains the fix.

This change only affects the RESTful client, which is never used within the

server-side installation of ModeShape.

All unit and integration tests pass with these changes.

MODE-1417 Corrected versioning of files uploaded through REST client

The REST client library was versioning only the 'jcr:content' child node of an

'nt:file' node. While that's acceptable (since it's where the file's content is

actually stored), it's better if the 'nt:file' node itself was versioned.

This change simply changes the node where the 'mix:versionable' mixin is applied.

When a new 'nt:file' node is uploaded, that node is now made versionable instead

of the 'jcr:content' child. All existing content is still handled and versioned

correctly (as it was), and this change only affects content added using a

RESTful client that contains the fix.

This change only affects the RESTful client, which is never used within the

server-side installation of ModeShape.

All unit and integration tests pass with these changes.

MODE-1417 Corrected versioning of files uploaded through REST client

The REST client library was versioning only the 'jcr:content' child node of an

'nt:file' node. While that's acceptable (since it's where the file's content is

actually stored), it's better if the 'nt:file' node itself was versioned.

This change simply changes the node where the 'mix:versionable' mixin is applied.

When a new 'nt:file' node is uploaded, that node is now made versionable instead

of the 'jcr:content' child. All existing content is still handled and versioned

correctly (as it was), and this change only affects content added using a

RESTful client that contains the fix.

This change only affects the RESTful client, which is never used within the

server-side installation of ModeShape.

All unit and integration tests pass with these changes.

Changed version to SNAPSHOT following release

  1. … 60 more files in changeset.
MODE-1397 Added JGroups based implementation for the ChangesBus

    • -0
    • +40
    /modeshape-jcr/src/main/java/org/modeshape/jcr/bus/ChangeBus.java
  1. … 4 more files in changeset.
MODE-1413 - Changed c3p0 to match the version deployed in AS

Merge branch 'mode-1414' of https://github.com/rhauch/modeshape into rhauch-mode-1414

MODE-1414 XMI model sequencer corrected to prevent NPEs

In certain cases, XMI models might contain references to the annotated objects not

as XML attributes but as child elements. (This bifurcated design is considered a

benefit to XMI, though not sure why.) Anyway, the problem appears to be that a virtual

model contains an (empty) "annoation" for the physical model. It's not clear to me

why the Designer would produce such an annotation.

Additional tests were added to reproduce the problem with the original models and VDB.

After the fix, the tests pass as expected.

All unit and integration tests pass with these changes.

MODE-1414 XMI model sequencer corrected to prevent NPEs

In certain cases, XMI models might contain references to the annotated objects not

as XML attributes but as child elements. (This bifurcated design is considered a

benefit to XMI, though not sure why.) Anyway, the problem appears to be that a virtual

model contains an (empty) "annoation" for the physical model. It's not clear to me

why the Designer would produce such an annotation.

Additional tests were added to reproduce the problem with the original models and VDB.

After the fix, the tests pass as expected.

All unit and integration tests pass with these changes.

MODE-1414 XMI model sequencer corrected to prevent NPEs

In certain cases, XMI models might contain references to the annotated objects not

as XML attributes but as child elements. (This bifurcated design is considered a

benefit to XMI, though not sure why.) Anyway, the problem appears to be that a virtual

model contains an (empty) "annoation" for the physical model. It's not clear to me

why the Designer would produce such an annotation.

Additional tests were added to reproduce the problem with the original models and VDB.

After the fix, the tests pass as expected.

All unit and integration tests pass with these changes.

MODE-1397 Added ValueMetric#EVENT_QUEUE_SIZE metric support

MODE-1397 Added unit test for RepositoryChangeBus

MODE-1397 Updated event bus to use 1 thread/event que/workspace/listener

- ported JcrObservationManagerTest from 2.x, but disabled some of the failing tests

- made ExecutionContext mutable in SessionCache, so that extra data (i.e. observation "userData" can be passed down)

MODE-1397 Updated and fixed some code for the Node.orderBefore operation

MODE-1397 Implemented Observation support, together with a standard event bus

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

  1. … 60 more files in changeset.
Minor changes and corrections.

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

  1. … 56 more files in changeset.
Updated release notes for 2.8.0.Final

MODE-1252 Added repository name constant in RepositoryFactory

Moved the URL an REPOSITORY_NAME constants from the JcrRepositoryFactory implementation

class into the existing org.modeshape.jcr.api.RepositoryFactory interface. These

constants can be used when programmatically defining the parameters to pass to the

RepositoryFactory.getRepository(Map) method.

Also added more JavaDoc, and deprecated the constants in the JcrRepositoryFactory class.

All unit and integration tests pass with these changes.

MODE-1252 Added repository name constant in RepositoryFactory

Moved the URL an REPOSITORY_NAME constants from the JcrRepositoryFactory implementation

class into the existing org.modeshape.jcr.api.RepositoryFactory interface. These

constants can be used when programmatically defining the parameters to pass to the

RepositoryFactory.getRepository(Map) method.

Also added more JavaDoc, and deprecated the constants in the JcrRepositoryFactory class.

All unit and integration tests pass with these changes.