ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-1269 Changed recently-added reindexing API

Having the maximum depth parameter in the reindex methods will likely cause far more issues and problems that will be difficult to track down. In fact, specifying the depth can be more optimum (but no better) than indexing to the fullest depth only in a few cases. Since keeping the depth parameter is extremely risky with very little benefit, I've removed the depth parameter from the public methods (which have not yet appeared in a release).

We may indeed discover that the depth is very useful, and if that's the case we can always add additional methods with a depth parameter. Adding methods to a public API is easy; removing methods is nearly impossible.

This testing also highlighted a bug in the way the Lucene indexes were updated to remove children below some depth. This bug was corrected.

As always, all unit and integration tests pass with these changes.

MODE-1269 Changed recently-added reindexing API

Having the maximum depth parameter in the reindex methods will likely cause far more issues and problems that will be difficult to track down. In fact, specifying the depth can be more optimum (but no better) than indexing to the fullest depth only in a few cases. Since keeping the depth parameter is extremely risky with very little benefit, I've removed the depth parameter from the public methods (which have not yet appeared in a release).

We may indeed discover that the depth is very useful, and if that's the case we can always add additional methods with a depth parameter. Adding methods to a public API is easy; removing methods is nearly impossible.

This testing also highlighted a bug in the way the Lucene indexes were updated to remove children below some depth. This bug was corrected.

As always, all unit and integration tests pass with these changes.

MODE-1224 Improved start performance

The startup time of a new repository was reduced by making a simple change to the way the node types are persisted. If existing node types are to be skipped, then we know that any requests to create new nodes will not replace existing content (since there is no existing content for nonexistent nodes).

An additional integration test was added to easily test this situation, using all of the node type CND files for all of the sequencers. Tests that use ModeShape with a local PostgreSQL database reduced the time required to register node types from ~11seconds to about 6 or 7 seconds. Hopefully this will have a similarly significant effect on the startup when using a remote database.

All unit and integration tests pass with these changes.

    • -0
    • +293
    /modeshape-integration-tests/src/test/resources/config/configRepositoryEdsWithJpaStore.xml
MODE-1224 Improved start performance

The startup time of a new repository was reduced by making a simple change to the way the node types are persisted. If existing node types are to be skipped, then we know that any requests to create new nodes will not replace existing content (since there is no existing content for nonexistent nodes).

An additional integration test was added to easily test this situation, using all of the node type CND files for all of the sequencers. Tests that use ModeShape with a local PostgreSQL database reduced the time required to register node types from ~11seconds to about 6 or 7 seconds. Hopefully this will have a similarly significant effect on the startup when using a remote database.

All unit and integration tests pass with these changes.

    • -0
    • +293
    /modeshape-integration-tests/src/test/resources/config/configRepositoryEdsWithJpaStore.xml
MODE-1263 Corrected indexing depth logic

The SearchEngineIndexer was doing math improperly. This doesn't appear to have affected any use cases except those that use the file system connector, since the file system connector uses its own maxDepth value (and ignores the value submitted by the indexer). It is in this case that the indexing stops one level too early.

Several new integration tests were created to verify the reported problems.

With a minor fix, the indexing operates correctly, and the new integration tests do indeed pass and demonstrate that the indexing (and the re-indexing) does indeed work properly.

MODE-1263 Corrected indexing depth logic

The SearchEngineIndexer was doing math improperly. This doesn't appear to have affected any use cases except those that use the file system connector, since the file system connector uses its own maxDepth value (and ignores the value submitted by the indexer). It is in this case that the indexing stops one level too early.

Several new integration tests were created to verify the reported problems.

With a minor fix, the indexing operates correctly, and the new integration tests do indeed pass and demonstrate that the indexing (and the re-indexing) does indeed work properly.

MODE-1224 Minor change to reduce wait times in a test

MODE-1224 Minor change to reduce wait times in a test

MODE-1224 Improved restart performance

Added quite a few debug logging statements to help identify the issue with startup times. Also added two info-level log messages around the node registration activity.

Created a test case that uses a slightly-modified EDS configuration (different index location in 'target' area, HSQLDB stored on disk in 'target' area), and starts then restarts the engine.

I was able to see the problem, and I believe it is solely because of the re-registration of the node types listed in the configuration file. I then changed the registration process to allow a flag that will not re-register the node type if a node type already exists with the same name (there was already a flag to fail if the node type exists), and changed the startup to a) not fail but b) to skip the registration for any node type that already exists.

After implementing this change, restarting appears to be significantly faster. If fact, my tests show that the time to register the node types in subsequent restarts goes from minutes to ~0.02 seconds.

All unit and integration tests pass.

    • -0
    • +69
    /modeshape-integration-tests/src/test/resources/config/configRepositoryWithAsynchronousIndex.xml
    • -0
    • +28
    /modeshape-integration-tests/src/test/resources/modeshape-initial-content.xml
MODE-1224 Improved restart performance

Added quite a few debug logging statements to help identify the issue with startup times. Also added two info-level log messages around the node registration activity.

Created a test case that uses a slightly-modified EDS configuration (different index location in 'target' area, HSQLDB stored on disk in 'target' area), and starts then restarts the engine.

I was able to see the problem, and I believe it is solely because of the re-registration of the node types listed in the configuration file. I then changed the registration process to allow a flag that will not re-register the node type if a node type already exists with the same name (there was already a flag to fail if the node type exists), and changed the startup to a) not fail but b) to skip the registration for any node type that already exists.

After implementing this change, restarting appears to be significantly faster. If fact, my tests show that the time to register the node types in subsequent restarts goes from minutes to ~0.02 seconds.

All unit and integration tests pass.

    • -0
    • +69
    /modeshape-integration-tests/src/test/resources/config/configRepositoryWithAsynchronousIndex.xml
    • -0
    • +28
    /modeshape-integration-tests/src/test/resources/modeshape-initial-content.xml
MODE-1273 Corrected Seam Security provider behavior

When the Seam Security API is available on the classpath, but it is not enabled for use

then the new provider was causing problems. A simple check fixes the problem.

MODE-1273 Corrected Seam Security provider behavior

When the Seam Security API is available on the classpath, but it is not enabled for use

then the new provider was causing problems. A simple check fixes the problem.

MODE-1267 Correct setting property to Value containing null

The JCR specification is not terribly clear on the behavior when null references are passed into the ValueFactory.create(…) methods. According to the JavaDoc, the spec, and the reference implementation, no error should be thrown. However, a ValueFormatException must be thrown when a non-null Value object (containing a null reference) is passed to Property.setValue(Value) or Property.setValues(Value[]) or Node.setProperty(String,Value) or Node.setProperty(String,Value[]). (Note that setting a property to a null Value reference is equivalent to removing the property.)

This change enables this behavior in ModeShape. Prior to this, ModeShape would allow setting a Value for a property even if that Value contained a null reference.

MODE-1267 Correct setting property to Value containing null

The JCR specification is not terribly clear on the behavior when null references are passed into the ValueFactory.create(…) methods. According to the JavaDoc, the spec, and the reference implementation, no error should be thrown. However, a ValueFormatException must be thrown when a non-null Value object (containing a null reference) is passed to Property.setValue(Value) or Property.setValues(Value[]) or Node.setProperty(String,Value) or Node.setProperty(String,Value[]). (Note that setting a property to a null Value reference is equivalent to removing the property.)

This change enables this behavior in ModeShape. Prior to this, ModeShape would allow setting a Value for a property even if that Value contained a null reference.

MODE-1273 Added built-in authentication using Seam Security

Added a built-in authentication/authorization provider to be enabled if and only if the "org.jboss.seam.security.Identity" class is on the classpath. The provider works when no Credentials are passed in, and creates an authenticated session based upon the current Identity instance if that Identity instance is already logged in.

All unit and integration tests pass with these changes, although none of our tests actually run with Seam Security. Therefore, additional testing will have to be done with system-level tests.

MODE-1273 Added built-in authentication using Seam Security

Added a built-in authentication/authorization provider to be enabled if and only if the "org.jboss.seam.security.Identity" class is on the classpath. The provider works when no Credentials are passed in, and creates an authenticated session based upon the current Identity instance if that Identity instance is already logged in.

All unit and integration tests pass with these changes, although none of our tests actually run with Seam Security. Therefore, additional testing will have to be done with system-level tests.

MODE-1270 Add support for setting Session's user ID based upon JAAS Subject in J2EE

The standard way to get the current JAAS Subject given the LoginContext or AccessController

works in standard Java but not in J2EE. Apparently this is a well-known issue. The recommended

approach for J2EE is to instead get the Subject via the JACC API.

This change adds an optional (e.g., "provided") dependency on the JACC API, changes

the JaasProvider implementation to accept an optional SubjectResolver implementation

that the provider will use to resolve the Subject should the standard JAAS technique

not work, and to change the JcrRepository implementation to give the JaasProvider

a new JaccSubjectResolver implementation (when the JACC API is available).

It is not really possible to test whether this technique works in our unit or integration

tests (as we don't deploy to a J2EE container). However, all existing unit and integration

tests do pass (meaning it doesn't break their functionality), and Kurt is verifying

that the JACC-style approach works within Guvnor and will (after this commit) verify

that these changes do indeed work within Guvnor (which uses Seam in JBoss AS).

MODE-1270 Add support for setting Session's user ID based upon JAAS Subject in J2EE

The standard way to get the current JAAS Subject given the LoginContext or AccessController

works in standard Java but not in J2EE. Apparently this is a well-known issue. The recommended

approach for J2EE is to instead get the Subject via the JACC API.

This change adds an optional (e.g., "provided") dependency on the JACC API, changes

the JaasProvider implementation to accept an optional SubjectResolver implementation

that the provider will use to resolve the Subject should the standard JAAS technique

not work, and to change the JcrRepository implementation to give the JaasProvider

a new JaccSubjectResolver implementation (when the JACC API is available).

It is not really possible to test whether this technique works in our unit or integration

tests (as we don't deploy to a J2EE container). However, all existing unit and integration

tests do pass (meaning it doesn't break their functionality), and Kurt is verifying

that the JACC-style approach works within Guvnor and will (after this commit) verify

that these changes do indeed work within Guvnor (which uses Seam in JBoss AS).

MODE-1150 Correct dependencies and documentation for SLF4J

Found some SLF4J dependencies that were still using the older version, plus the documentation

should have been updated.

    • -1
    • +0
    /web/modeshape-web-jcr-rest-war/pom.xml
    • -1
    • +0
    /web/modeshape-web-jcr-webdav-war/pom.xml
MODE-1150 Correct dependencies and documentation for SLF4J

Found some SLF4J dependencies that were still using the older version, plus the documentation

should have been updated.

    • -1
    • +0
    /web/modeshape-web-jcr-rest-war/pom.xml
    • -1
    • +0
    /web/modeshape-web-jcr-webdav-war/pom.xml
MODE-1269 Methods to re-index workspace content are now public

The re-indexing methods were previously on JcrSession, which was a package-protected

class, and thus the re-indexing methods were not publicly accessible. This change

moves the methods to the org.modeshape.jcr.api.Workspace interface is ModeShape's

public API. Now there are synchronous and asynchronous methods to re-index the entire

workspace and to re-index a subgraph below some path to a maximum depth.

Additional tests were added to verify the methods work. All unit and integration

tests pass.

MODE-1269 Methods to re-index workspace content are now public

The re-indexing methods were previously on JcrSession, which was a package-protected

class, and thus the re-indexing methods were not publicly accessible. This change

moves the methods to the org.modeshape.jcr.api.Workspace interface is ModeShape's

public API. Now there are synchronous and asynchronous methods to re-index the entire

workspace and to re-index a subgraph below some path to a maximum depth.

Additional tests were added to verify the methods work. All unit and integration

tests pass.

MODE-1262 Temporary fix to unpublish the file published in the test. This patch needs to be removed when the problem is resovled

MODE-1262 Temporary fix to unpublish the file published in the test. This patch needs to be removed when the problem is resovled

MODE-1263 Corrected indexing logic for file system content

Added the integration test supplied by Danny (with some minor modifications) and updated the @Before method in the FileSystemRepositoryIntegrationTest, and verified the query does not include any of the files or folders already present on the file system.

After a bit of debugging, I was able to figure out what the problem is and why we're only seeing it for the file system connector.

The actual bug is in SearchEngineIndexer logic: when the subgraph comes back with just a single node (i.e., the subgraph only contains a single level), the loop at line 336 will exit without processing the children of the single node in the subgraph. The fix is to check for this condition and add the children to the locationsToRead list before going into the loop.

The problem only manifests itself with the FileSystemConnector because it is the only connector to override the 'absoluteMaximumDepthForBranches()' method to return 1. All other connectors return the default value, 4 (or some other number > 1), and therefore the subgraph contains multiple levels and the while loop is entered and the children processed.

After the fix to SearchEngineIndexer, all unit and integration tests pass, including the new integration test.

Thanks again to Danny C for identifying this issue and creating an easily reproducible test case!

MODE-1263 Corrected indexing logic for file system content

Added the integration test supplied by Danny (with some minor modifications) and updated the @Before method in the FileSystemRepositoryIntegrationTest, and verified the query does not include any of the files or folders already present on the file system.

After a bit of debugging, I was able to figure out what the problem is and why we're only seeing it for the file system connector.

The actual bug is in SearchEngineIndexer logic: when the subgraph comes back with just a single node (i.e., the subgraph only contains a single level), the loop at line 336 will exit without processing the children of the single node in the subgraph. The fix is to check for this condition and add the children to the locationsToRead list before going into the loop.

The problem only manifests itself with the FileSystemConnector because it is the only connector to override the 'absoluteMaximumDepthForBranches()' method to return 1. All other connectors return the default value, 4 (or some other number > 1), and therefore the subgraph contains multiple levels and the while loop is entered and the children processed.

After the fix to SearchEngineIndexer, all unit and integration tests pass, including the new integration test.

Thanks again to Danny C for identifying this issue and creating an easily reproducible test case!

MODE-1259 change the assembly to attach to mead repo, incorrectly change the wrong attach property

MODE-1259 change the assembly to attach to mead repo, incorrectly change the wrong attach property

MODE-1261 Fixed JackrabbitXmlNodeTypeRegistrationTest on Solaris.

BOM (Binary Order Mark) at the start of owfe_nodetypes.xml file was causing failing of two tests on Solaris 9 machines. BOM was deleted.

MODE-1261 Fixed JackrabbitXmlNodeTypeRegistrationTest on Solaris.

BOM (Binary Order Mark) at the start of owfe_nodetypes.xml file was causing failing of two tests on Solaris 9 machines. BOM was deleted.