[
https://issues.apache.org/jira/browse/JCR-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-840.
------------------------
Resolution: Duplicate
this is a sub-task of the more general issue JCR-2195.
resolving as duplicate
> Support for setting jcr:created when importing Into the repository
> -------------------------------------------------------------------
>
> Key: JCR-840
> URL: https://issues.apache.org/jira/browse/JCR-840
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: JCR 1.0.1, JCR 2.0
> Affects Versions: 1.2.3, 1.4, 2.0.0
> Environment: Java 1.6_01, Tomcat 5.5.x, Postgresql 8.2
> Reporter: Julian Klein
> Priority: Minor
>
> When importing content from one repository or source into Jackrabbit, it is
> impossible to set the jcr:created property. The specification indicates that
> the property is protected, however section 7.3 indicates that "Level 2
> Repositories must support the import of content". It goes on to read in
> section 7.3.3,
> "When an element or attribute representing such a property is encountered, an
> implementation may either skip it or respect it. To respect it means to
> import it and alter the internal state of the repository in accordance with
> the semantics of the property in the given implementation. .... To skip the
> element or attribute means not to import it all. It does not mean to import
> it but then ignore its semantic implications.
> The implementation-specific policy regarding what to skip and what to respect
> must be internally consistent. For example, it makes no sense to skip
> jcr:mixinTypes (thus missing the presence of mix:lockable, for example) and
> yet respect jcr:lockOwner and jcr:lockIsDeep."
> Overall, the ability to set the value of jcr:created when importing content
> will allow conversion from other repositories (e.g Apache Slide) to
> Jackrabbit as well as allowing a complete export of the jackrabbit repository
> to be restored to its proper state at a later point in time. Setting the
> value could be done during the execution of the importXML and
> getImportContentHandler methods available to the Session and the Workspace
> objects. By supporting this one could transition to jackrabbit and the dates
> of creation from the original repository (e.g. again Slide) would reflect the
> origins of the repository rather than the date when the transition occurred.
> Finally, this is not to be confused with the various restore methods in the
> JCR API which allow for restoring a node or workspace to a previous state
> (versioning).
> see the mailing lists discussion that spawned this issue:
> http://article.gmane.org/gmane.comp.apache.jackrabbit.user/2790
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
