[
https://issues.apache.org/jira/browse/JCRVLT-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515945#comment-17515945
]
Konrad Windszus commented on JCRVLT-623:
----------------------------------------
IMHO parsers should not try to fix those invalid input and just fail. More
recent FileVault versions do so as well during import of packages containing
such invalid properties, so I don't think that a third party parser should try
to be more lenient than the FileVault importer is...
> Validate that DocView values for a specific type are correct serializations
> (i.e. are a string which can be converted back to the given type)
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-623
> URL: https://issues.apache.org/jira/browse/JCRVLT-623
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Affects Versions: 3.6.0
> Reporter: Konrad Windszus
> Priority: Major
>
> This came up in the context of SLING-11240. Sometimes DocView XML files
> contain invalid property values, like
> {code:xml}
> test="{Long}1.0"
> {code}
> Those should be detected by the {{jackrabbit-docviewparser}} validator as
> they can never be applied to a JCR node. Currently the exception is only
> thrown during the actual import of those files, but not during parsing.
> Either the exception could be generated from the validator implementation or
> whenever such an invalid string value is being detected in the
> {{DocViewProperty2.parse(...)}} method, but I am not sure how big the
> overhead is of always calling
> https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/value/ValueHelper.java#L779.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
