[
https://issues.apache.org/jira/browse/JCR-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Klein updated JCR-840:
-----------------------------
Description:
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
was:
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
confuse 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
> Support for setting jcr:created when importing Into the repository
> -------------------------------------------------------------------
>
> Key: JCR-840
> URL: https://issues.apache.org/jira/browse/JCR-840
> Project: Jackrabbit
> Issue Type: Improvement
> Components: JCR 1.0.1, JCR 2.0
> Affects Versions: 1.2.3, 1.4, 2.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.
