[ 
http://issues.apache.org/jira/browse/JCR-325?page=comments#action_12371095 ] 

Stefan Guggisberg commented on JCR-325:
---------------------------------------

i'm not sure regarding preserving the current (i.e. local, scoped) namespace 
context 
from the xml document within the StringValue & BufferedStringValue instances.

in your patch you just pass a reference to the ns context in the constructor.
the ns context however is mutable and could, theoretically at least, change
after a *StringValue has been created and before getValue has been called.

there should at least be a warning that the values have to be processed
during the Importer.startNode call. ohterwise the ns context should be cloned. 
that however would significantly increase memory usage compared to the current 
approach.

apart from this the patch looks good to me.

> 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: Improvement
>   Components: xml
>     Versions: 0.9
>  Environment: jackrabbit r379292
>     Reporter: Tobias Bocanegra
>     Assignee: Jukka Zitting
>  Attachments: xml-refactoring.patch
>
> 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

Reply via email to