…'t update node types.
The logic was incorrectly replacing blank values with null values. All works well now.
Forgot to update VDB in the integration project. Also fixed a schema validation error in the VDB manifest.
…cified in its "vdb.xml" Cleaned up debug logging to make it consistent with the rest of ModeShape.
…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.
…not configured: a dedicated exception should be thrown
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.
…ValueOperation, still doesn't solve problem as we start to get NullPointerException in ArrayOperation.mutableParent
…es the standard assembly mechanism to attach (install & deploy) the artifact
Applied several corrections suggested by Horia during the code review.
Prior to this fix, authenticators were used but were lost when the configuration was written back out. It was also not possible to dynamically add/remove authenticators via the CLI or other administrative tools. This change adds all of this functionality.
This constructor was accidentally removed in a recent refactoring (see MODE-1669). I've now added a test case that uses externalization (via a file system cache store) and replicates the problem. Adding the no-arg constructor fixes the issue.
…cnd files are configured in the repository
Prior to this, there were two `isReference(Property)` utility methods (one in SessionNode and the other in WritableSessionCache). These were removed and a new method added to the org.modeshape.jcr.value.Property interface. This is better because the logic is now centralized, and it also allows for the empty, single- and multi-valued Property implementations to contain efficient implementations. (I didn't do this originally because I was trying to minimize the impact of the changes. But in reality there are new methods and making this change is far better than having duplicate code. Thanks, Horia.)
When nodes were removed, their REFERENCE properties were not being processed to remove the opposite references (from the target of the REFERENCE to the referrer, used for referential integrity and returning the nodes that refer to a particular node. As a result, removing the only REFERENCE properties pointing to a particular node would incorrectly prevent the removal of the referenced node (even when there were no more nodes referring to it). Added some logic to correctly process these REFERENCE properties when the nodes are being removed, ensuring the correctness of the referential integrity states. Several unit tests were added to first replicate and then verify the correct behavior.
…kspace cache container