[ http://issues.apache.org/jira/browse/JCR-325?page=comments#action_12369617 ]
Stefan Guggisberg commented on JCR-325: --------------------------------------- the multi-value attribute is one of the differentiators being use to identify applicable property definitions. nt:unstructured for example defines 2 residual properties that only differ in the multi-value attribute. your approach would not be able to unambiguously determine the 'correct' definition because the 'multi-valued' information is lost in document view . btw: i just realized that some related test-cases fail after my changes. i'll have to find out if they do so legitimatly or whether they have to be adapted. > docview roundtripping does not work with multivalue non-string properties > ------------------------------------------------------------------------- > > Key: JCR-325 > URL: http://issues.apache.org/jira/browse/JCR-325 > Project: Jackrabbit > Type: Bug > Components: core > Versions: 0.9 > Environment: jackrabbit r379292 > Reporter: Tobias Bocanegra > Assignee: Stefan Guggisberg > > when exporting a multivalue property with docview, the property values are > serialized to a space delimited list in the xml attributes: > for example: > <?xml version="1.0" encoding="UTF-8"?> > . > . > <testNode > jcr:primaryType="refTest" > refs="b5c12524-5446-4c1a-b024-77f623680271 > 7b4d4e6f-9515-47d8-a77c-b4beeaf469bc" > /> > the refTest nodetype was: > [refTest] > - refs (reference) multiple > importing this docview fails with: javax.jcr.ValueFormatException: not a > valid UUID format > this is due to the fact, that the space delimited list is not exploded > anymore. actually this code is commented: > org.apache.jackrabbit.core.xml.DocViewImportHandler, lines 191 - 200: > /* > // @todo should attribute value be interpreted as LIST type > (i.e. multi-valued property)? > String[] strings = Text.explode(attrValue, ' ', true); > propValues = new Value[strings.length]; > for (int j = 0; j < strings.length; j++) { > // decode encoded blanks in value > strings[j] = Text.replace(strings[j], "_x0020_", " "); > propValues[j] = InternalValue.create(strings[j]); > } > */ > i haven't tested, but i assume this also fails for all other non-string > property types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
