[overlord-issues] [JBoss JIRA] (SRAMP-535) Correct JCR trash path
Brett Meyer (JIRA)
issues at jboss.org
Thu Oct 2 13:24:02 EDT 2014
[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Meyer resolved SRAMP-535.
-------------------------------
Resolution: Done
> Correct JCR trash path
> ----------------------
>
> Key: SRAMP-535
> URL: https://issues.jboss.org/browse/SRAMP-535
> Project: S-RAMP
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.5.0.Beta3
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
More information about the overlord-issues
mailing list