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.
…connectors ISPN 5 uses a newer version of jboss-logging, therefore when this connector is used, some transitive dependencies need to be disabled
…uest is always frozen
…te hangs when repository starts up. Also, added a test case which reproduces the steps in MODE-1235
Without this, the Java Sequencer and the JBoss AS assembly would bring in 2 different versions, causing the Ant script from JBossAS to fail when unsigning the jar.
The fix allows changes to be recorded & dispatch always (not only when the source and target of the projection are the same)
…s in a disk store
…ted issues may be easily verified
The examples in the RESTful Service chapter did not show including the "Content-Type" HTTP header. The service will correctly return JSON if this header or "Content-Type" header is supplied in the request. However, an error will result if a different content-Type header is provided. This change only affects the Reference Guide.
Corrected several behaviors of what is allowed and not allowed for modifying nodes that are checked in, per Section 15.2.2 of the JCR specification. Several new unit tests were added that verify these behaviors. These new tests all failed prior to these fixes, but they all pass now. (Note this clearly shows the incomplete coverage of the TCK versioning tests.) All unit and integration tests pass with these changes.
…CND files Previously, the CND files were being read but any problems during the reading were not reported and were simply ignored. Some errors cause the reader to abort reading and to have successfully read in no node types, so registration appeared to do nothing while hiding the errors. With these changes, the errors and warnings are included in a thrown exception; if there are no errors and only warnings, the warnings are simply logged. All unit and integration tests pass.
…side finally construct
…arch multiple times The fix was part of the #207 pull request, which basically removed explicit synchronization around the LuceneSearchProcessor and Engine. In addition: - the lucene version was updated from 3.1.0 to 3.4.0 - the LuceneSearchSession was updated to avoid the possible loss of content when indexing the same content in the same workspace from multiple threads
Made additional changes/fixes to the Infinispan 4 and 5 connectors and tests.
Two issues fixed: - refresh phase 1 - determining which nodes should be left and which should be discarded - LinkedListMultimap clear method, which cause refresh phase 2 to incorrectly duplicate existing nodes under a parent, as SNS.
Added a new connector that uses Infinispan 5.x caches for storage. The existing Infinispan 4.x connector is still usable, and basically users would choose between the two. Note that Infinispan 5.1.1.Final is likely to be used by JBoss AS 7.1.0.Final. All unit and integration tests pass.
… statements The fix was to implement minimal support for unique index in the Oracle parser and to make sure that only "legal" token are delegated to the standard parser.
- changed request path parsing so that multiple empty '/' characters are collapsed into one. - updated pom.xml so that log4j dependency is runtime (this is not ideal, but until slf4j dependencies are changed, this should be there)
The JcrNodeDefinition is intended to be immutable and thread-safe, and although it is publicly immutable, internally it delays loading the references to the required primary types until needed. The 'ensureRequiredPrimaryTypesLoaded()' method is what lazily initializes the references, and this method is properly called in the right spots within JcrNodeDefinition. However, in a highly-concurrent environment a node type definition may be needed by multiple threads, and this can result in this method being called concurrently. Unfortunately this method is not thread-safe, and can cause a NullPointerException when used concurrently. The 'ensureRequiredPrimaryTypesLoaded()' method just iterates through the names of the required primary types (which were set in the constructor), and looks up the JcrNodeType instances for each primary type name. It then creates an immutable map to quickly find the JcrNodeType instances given the primary type name. Finally, it stores the map and the names, and when the array of JcrNodeType instances and map are available (non-null), it merely uses the values. But the creation of the JcrNodeType array and map keyed by name are not concurrent or atomic. In fact, a non-empty array is created (but not initialized, so it contains null references) and _immediately set_ on one of the JcrNodeDefinition fields, so when the method is called by other threads it is as if the JcrNodeType array is ready to be used. But the original thread hasn't yet set the JcrNodeType references in the array, so any other thread that uses the array gets a null reference instead, and using that causes the NullPointerException. The fix is relatively simple: ensure that the 'requiredPrimaryTypes' array of JcrNodeType and 'requiredPrimaryTypesByName' map are set in a synchronized way, ensuring they are only set to non-null with an array (or map) that are fully and correctly populated. This could be done by simply synchronizing the entire 'ensureRequiredPrimaryTypesLoaded()' method, but the method calls out to the RepositoryNodeTypeManager. And while the RNTM doesn't currently (directly or indirectly) result in a call to 'ensureRequiredPrimaryTypesLoaded()', it's possible it might in the future. Therefore, we can simply create and fully-populate the array and map outside of the synchronization block, and only synchronize upon setting it (of course checking before we set it whether another thread snuck in and set it while we waited for the lock). So it is effectively the same as synchronizing the method (which the reporter says fixes the problem), but does it with smaller lock scope. With this change, all unit and integration tests pass.
Added three unit tests that verified the ObservationManager.setUserData() is being set correctly. All tests pass, with no changes to the non-test code, proving the code is indeed working correctly.
Updated the two COPYRIGHT.txt files and also updated the two AUTHOR.txt files to reflect the contributors.
…oting The JCR-SQL2 grammar uses square brackets for quoting identifiers, node names and node paths. However, path literals may also have square brackets around the same-name-siblings. The JCR-SQL2 parser was not able to properly parse quoted paths with SNS indexes. The fix is to adjust the tokenizer to count the number of open and close square brackets, and to stop the quoted string token when the all of the opened square brackets were closed. Additional unit tests were added to verify the tokenizer and JCR-SQL2 parser behavior. All unit and integration tests pass with these changes.
The JcrDriverIntegrationTest queries the output of the DDL sequencer, and so required changes to the expected results to mirror the updated output.
…e ddl sequencer
The indexes were not storing the value of REFERENCE or WEAK REFERENCE properties, and thus null was returned in the tuples for these records. Consequently, the join could not be performed with null values. Added several test cases that replicated this problem and now verify the updated code exhibits the correct behavior.