MODE-1513 Merge 'federation' branch onto 'master' #618
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ValueOperation, still doesn't solve problem as we start to get NullPointerException in ArrayOperation.mutableParent
Array objects were not being serialized/deserialized properly within the delta's operation instances (e.g., PutOperation). Normally, all SchematicEntry (e.g., Documents containing values such as Arrays and other Documents) are serialized using BSON, and this works correctly in the non-clustered case. However, in the clustered case, the changes made to one Document are recorded to create a SchematicEntryDelta that is shipped across the Infinispan cluster. (This way we can ship only the changes to the SchematicEntry rather than the whole document.) Thus the problem only manifest itself in clustered configurations. The actual problem stemmed from the fact that an SchematicEntryDelta and its Operation objects are all externalizable (with custom Externalizers). The Operation objects can contain individual values, Document or Array objects. These are also externalizable, but there was a single DocumentExternalizer for both Document and Array objects and the DocumentExternalizer wrote/read both to/from BSON. However, the BSON format (which is simply a binary representation of JSON documents, with a few extra value types) is only valid for Documents; a standalone Array cannot be written in BSON format. The solution was to use the DocumentExternalizer for Documents, but a new ArrayExternalizer for Arrays. This ArrayExternalizer still uses BSON, but it uses a subset of the BSON representation to serialize Array objects. But, it does work well and fixes the problem. Quite a few new tests were added to verify that the various operations with various parameters are indeed externalizable. The tests don't cover all the permuations, but they do attempt to cover the different kinds of operations with documents and arrays. To make the Operation objects easily testable, equals and hashCode methods were added to all the Operation subclasses. Additionally, all of the externalizers were manually reviewed for asymmetric read and write methods (e.g, writing an object to the ObjectOutputStream but reading an integer from the ObjectInputStream), and several asymmetries were found in the Externalizers for BSON value types that ModeShape doesn't currently use, and these asymmetries were corrected. All unit and integration tests pass with these changes.
Based upon feedback, two sections of commented-out code were removed (they'd been there for some time) and the Code.Externalizer methods were changed to use constants rather than magic numbers for the types of the Code classes.
…not configured: a dedicated exception should be thrown
…cified in its "vdb.xml" MODE-1700 Teiid Model Sequencer Throws Error When Model Import Has Annotation MODE-1702 Cleanup Corrupted Teiid Sequencer VDB Test Data Removed corrupted zip files from test data. Removed ignored tests that used those corrupted zip files. Added new VDBs to test data and added tests for those new VDBs. The new vdb.xml file XSD included VDB dependendencies and model metadata which uses DDL to define the model. Modified VDB sequencer and model sequencer to include these new VDB manifest features. Also added tests that test these new features. Fixed an error where the href of a model import was not being processed.
…cified in its "vdb.xml" Cleaned up debug logging to make it consistent with the rest of ModeShape.
Forgot to update VDB in the integration project. Also fixed a schema validation error in the VDB manifest.
The logic was incorrectly replacing blank values with null values. All works well now.
…'t update node types.
…n existing running transaction. This is required so that a repository is "atomically" configured on start-up.
…initions If a CND file contains a node type with a property definition that has a required type of URI, then this property definition was incorrectly being created with a type of STRING rather than URI. Added a test case to fail with this incorrect behavior, and then corrected the PropertyTypeUtil method that was determining the JCR property type from the string name. The new test and all other tests now pass.
…lowed Moving a child node to a different name would not work if the child node definition does not allow same-name-sibling nodes. A simple fix to the JcrSession.move method fixed the problem. A new test case verifies the behavior is now correct.
ExecutionContext contains quite a few objects that represent the context-specific factories, namespace registries, binary stores, etc. The nature of these components made it difficult to created altered contexts with customized value factories, security contexts, binary stores, etc. ExecutionContext was refactored to own all of the value factory implementations, and all of the factories were changed to take "holder"-type objects that the factories use to get the components they want. These two steps make it far easier for ExecutionContext to create alterations. These changes are simple refactorings of existing behavior, and as such made it easier to verify that the functionality remainined unchanged. This commit will then serve as a baseline for other changes specific to MODE-1720.
When REFERENCE properties are set with Value objects created from node identifier strings, the values were not correctly being converted (internally) to NodeKey representations. The result was that the REFERENCE values were not usable. A new test case verifies this behavior. The challenge was that the logic was using the ReferenceFactory (in the ValueFactories inside the Session's ExecutionContext) to perform the conversion. However, the conversion requires knowledge of the root NodeKey, of which the ReferenceFactory was not aware. The fix was to give each Session a new ExecutionContext with a custom ReferenceFactory implementation that knows about the workspace's root node key, allowing the factory to create REFERENCE (and WEAKREFERENCE) values from string Node identifiers. Note that this resulted in a failure of a TCK test, whereby a node of type "nt:unstructured" had an existing REFERENCE property that was set to a STRING value (e.g., "Hello World") that was not convertable to a reference. This failure actually highlighted an existing bug: the internal AbstractJcrNode.setProperty(...) method did not check whether the new value had the same node type as the required type on the existing property's property definition. Because the types differed in this case, a new property definition needed to be found given the value.
Conflicts: modeshape-jcr/src/main/java/org/modeshape/jcr/JcrRepository.java modeshape-jcr/src/test/java/org/modeshape/jcr/JcrNodeTypesTest.java modeshape-jcr/src/test/java/org/modeshape/jcr/JcrRepositoryStartupTest.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Only a few minor conflicts needed to be resolved.