[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