[
https://issues.apache.org/jira/browse/JCR-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676647#action_12676647
]
Marcel Reutegger commented on JCR-1996:
---------------------------------------
> Is this also solved by the patch?
no, it isn't. My test used a time that wasn't far enough in the future ;)
The problem is the five digit year. Bundle persistence managers store a date
property as a string representation and on read parse the string using
ISO8601.parse(String). This method returns null when there are five year digits.
Hmm, I'm not sure how this should be fixed. The specification says that a date
is converted to String using ISO8601, but it doesn't say what should happen
when the year cannot be represented with four digits. At the same time
ValueFactory.createValue(Calendar) does not declare an exception, which makes
it difficult to prevent such values. We might be able to throw an exception on
setProperty() though. I'll have to check....
> Handle date values in the far future or prevent these from being persisted
> --------------------------------------------------------------------------
>
> Key: JCR-1996
> URL: https://issues.apache.org/jira/browse/JCR-1996
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: indexing, jackrabbit-core
> Affects Versions: 1.5.3
> Reporter: Martijn Hendriks
> Attachments: JCR-1996.patch
>
>
> Setting a date property with a value in the far future (e.g., the year 20009)
> and saving the session causes the index component to throw an exception (see
> the DateField#timeToString method). Furthermore, when the repository is
> restarted, the properties' value cannot be retrieved anymore because of a
> ValueFormatException caused by an empty value. Restarting the repository with
> an empty search index does not work because indexing fails. I haven't looked
> into the effect on queries.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
