Corrects the description of constructor detection.

Closes #2401
Original pull request: #2402.

Author: schauder

src/main/asciidoc/object-mapping.adoc

@@ -17,10 +17,10 @@ This means we need two fundamental steps:
 Spring Data automatically tries to detect a persistent entity's constructor to be used to materialize objects of that type.
 The resolution algorithm works as follows:
 
-1. If there's a no-argument constructor, it will be used.
+1. If there is a single constructor, it is used.
+2. If there are multiple constructors and exactly one is annotated with `@PersistenceConstructor`, it is used.
+3. If there's a no-argument constructor, it is used.
 Other constructors will be ignored.
-2. If there's a single constructor taking arguments, it will be used.
-3. If there are multiple constructors taking arguments, the one to be used by Spring Data will have to be annotated with `@PersistenceConstructor`.
 
 The value resolution assumes constructor argument names to match the property names of the entity, i.e. the resolution will be performed as if the property was to be populated, including all customizations in mapping (different datastore column or field name etc.).
 This also requires either parameter names information available in the class file or an `@ConstructorProperties` annotation being present on the constructor.
@@ -35,7 +35,7 @@ Please consult the section on store specific mappings for further details.
 To avoid the overhead of reflection, Spring Data object creation uses a factory class generated at runtime by default, which will call the domain classes constructor directly.
 I.e. for this example type:
 
-[source, java]
+[source,java]
 ----
 class Person {
   Person(String firstname, String lastname) { … }