ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.

MODE-1264 Upgraded webdav-servlet to 2.0.1

Also updated the documentation to reference the new version.

MODE-1259 Change modeshape-distribution pom.xml to attach javadocs to the mead repository

MODE-1259 Change modeshape-distribution pom.xml to attach javadocs to the mead repository

MODE-1256 Corrected federated move logic

The move logic within the join process of the federated connector was incorrectly setting the actual location of the node after it was moved. Because this happens after the source connector performed the move, the node was indeed moved. The error occurred during the federation of the source results, and thus caused a problem with the JCR layer. The fix was a simple correction.

This change adds new integration test that replicates the reporter's configuration (but with an in-memory instead of a file system source). Before the fix, this test did replicate the reported exception, and after the fix the test succeeds.

All unit and integration tests pass with these changes.

    • -0
    • +41
    /modeshape-integration-tests/src/test/resources/config/configRepositoryForFederatedInfinispan.xml
MODE-1256 Corrected federated move logic

The move logic within the join process of the federated connector was incorrectly setting the actual location of the node after it was moved. Because this happens after the source connector performed the move, the node was indeed moved. The error occurred during the federation of the source results, and thus caused a problem with the JCR layer. The fix was a simple correction.

This change adds new integration test that replicates the reporter's configuration (but with an in-memory instead of a file system source). Before the fix, this test did replicate the reported exception, and after the fix the test succeeds.

All unit and integration tests pass with these changes.

    • -0
    • +41
    /modeshape-integration-tests/src/test/resources/config/configRepositoryForFederatedInfinispan.xml
MODE-1244: Fix for NPE while server is being restarted

MODE-1244: Fix for NPE while server is being restarted

MODE-1254 Okay to call toString on ModeShape's Node and Property objects with Binary values

Large Binary values would cause an out-of-memory exception when 'toString()' is called.

This change corrects that behavior to place "**binary-value**" in the toString() result

any place where a Binary value is encountered.

A new unit test was added to verify the behavior, and all unit and integration tests pass.

MODE-1254 Okay to call toString on ModeShape's Node and Property objects with Binary values

Large Binary values would cause an out-of-memory exception when 'toString()' is called.

This change corrects that behavior to place "**binary-value**" in the toString() result

any place where a Binary value is encountered.

A new unit test was added to verify the behavior, and all unit and integration tests pass.

MODE-1257 Corrected class cast exception

The JoinRequestProcessor.process(RemovePropertyRequest) was incorrectly casting the forked request

to SetPropertyRequest. This was a copy-and-paste error, and fixing it appears to fix the issue.

(Additional tests being added under MODE-1256.)

All unit and integration tests pass with these changes.

MODE-1257 Corrected class cast exception

The JoinRequestProcessor.process(RemovePropertyRequest) was incorrectly casting the forked request

to SetPropertyRequest. This was a copy-and-paste error, and fixing it appears to fix the issue.

(Additional tests being added under MODE-1256.)

All unit and integration tests pass with these changes.

MODE-1255 Corrected 'restore' logic

The logic for restoring nodes was not correctly getting the 'jcr:primaryType' value when checking

if the node in version history had a primary type of 'nt:frozenNode': it was comparing the

'nt:frozenNode' Name constant to the Property object (rather than the first value of the Property).

Thus, the if-check never succeeded, and the node is restored with a primary type of 'nt:frozenNode'.

After the simple fix, all unit and integration tests pass.

MODE-1255 Corrected 'restore' logic

The logic for restoring nodes was not correctly getting the 'jcr:primaryType' value when checking

if the node in version history had a primary type of 'nt:frozenNode': it was comparing the

'nt:frozenNode' Name constant to the Property object (rather than the first value of the Property).

Thus, the if-check never succeeded, and the node is restored with a primary type of 'nt:frozenNode'.

After the simple fix, all unit and integration tests pass.

Ignored .log files (the correct way)

Ignored .log files (the correct way)

Ignored .log files

Ignored .log files