Under certain situations, AbstractJcrNode attempts to create a JcrSingleValuedProperty object when the property definition is multi-valued.

I ran into this when implementing the Git connector. The FederatedDocumentWriter.addProperty(...) methods that take an array of values will create an SingleValuedProperty object even when there is only one value; this is due to the assertions and documentation in the MultiValuedProperty class that there must be at least 2 values. So when a connector adds a property that has a multi-valued definition but only a single value, a SingleValuedProperty is used. Then, in AbstractJcrNode.createJcrProperty(...) method, the number of values is used to determine whether to create a JcrSingleValuedProperty or a JcrMultiValuedProperty, even though that same method has already determined the applicable property definition that knows whether it is multi-valued.

(Note that the property definition is found by looking at the number of values. If the property is single-valued and only a multi-valued definition can be found, then the multi-valued definition will be used.)

Therefore, the AbstractJcrNode.createJcrProperty(...) method should use the property definition's knowledge about being multi-valued to determine whether to create a JcrSingleValuedProperty object or JcrMultiValuedProperty object.

I suspect this hasn't really been a problem because with 3.0.0 and 3.0.1, the values stored in Infinispan always matched the multiplicity of the definition. However, in 3.1 we now have connectors that are producing their own Document representations, and the multiplicity of the property may not match that of the definition.