[
https://jira.jboss.org/jira/browse/DNA-439?page=com.atlassian.jira.plugin...
]
Brian Carothers updated DNA-439:
--------------------------------
Attachment: DNA-439.patch
Attached patch that adds a custom type required for the test and modifies the repository
stub properties to utilize the new type.
More importantly, the patch also modifies the behavior of
RepositoryNodeTypeManager.findBestPropertyDefinition to change the order of importance of
the three dimensions of the property (name, type, cardinality). Previously, the RTNM.fBPD
method would first try to match on name, type, and cardinality. If that did not work, it
would try to match on name and type. If that did not work, it would try to map on name
and any type that could be converted to the correct type. If all of those failed, it
would try again searching for residual properties. This creates a problem in that a node
type may declare a named property (e.g., "prop1" with type DATE) and a residual
property (e.g., with type BOOLEAN). The prior method would return the residual property
as a best match for property "prop1" with type BOOLEAN. In our type system
(which, admittedly, was almost entirely written after this method was last modified), this
should return no match to avoid violating the node type's contract for the type of
"prop1".
The modified version first tries to match on name. If any definitions are found for the
name, the method tries to match on exact type and cardinality. Failing that, it tries to
match the named definition on cardinality and a convertible type. Failing that, it
(optionally, depending on the arguments) attempts to match on type without regards to
cardinality. Finally, it attempts to match on name and the convertible type. If there is
no match for the requested type on the named property, it returns no match instead of
proceeding on to try to match a residual definition.
This is a pretty key conceptual change to the way that the method works, although it is
consistent with out typing rules, so I'm going to leave this patch out there for a day
or two for comment.
JcrNode.setProperty(String, String|Value, int) Doe sNot Always Throw
ConstraintViolationException Correctly
-----------------------------------------------------------------------------------------------------------
Key: DNA-439
URL:
https://jira.jboss.org/jira/browse/DNA-439
Project: DNA
Issue Type: Bug
Affects Versions: 0.4
Reporter: Brian Carothers
Assignee: Brian Carothers
Priority: Minor
Fix For: 0.5
Attachments: DNA-439.patch
The JR TCK test SetPropertyAssumeTypeTest has two test cases for Node.setProperty(String,
String|Value, int) with invalid types. Both are currently failing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira