[
https://issues.apache.org/jira/browse/JCR-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated JCR-3672:
-------------------------------
Description: When SessionImporter#resolveUUIDConflict(parent,
conflictingId, nodeInfo) is called and uuidBehavior is set to
ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW an exception is thrown with a
message saying that a node with the same UUID already exists. We have found
that usually when this happens it would be very handy to know the path of the
conflicting node. Right now, whenever this happens we need to attach a debugger
to find the conflicting node. Could conflicting.getPath() be added to the
message, so there is no need to attach a debugger to find that path? (was:
When {{SessionImporter#resolveUUIDConflict(parent, conflictingId, nodeInfo)}}
is called and {{uuidBehavior}} is set to
{{ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW}} an exception is thrown with
a message saying that a node with the same UUID already exists. We have found
that usually when this happens it would be very handy to know the path of the
conflicting node. Right now, whenever this happens we need to attach a debugger
to find the conflicting node. Could {{conflicting.getPath()}} be added to the
message, so there is no need to attach a debugger to find that path?)
> Log path of conflicting node when importing a node while another node with
> the same UUID already exists
> -------------------------------------------------------------------------------------------------------
>
> Key: JCR-3672
> URL: https://issues.apache.org/jira/browse/JCR-3672
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.4.4
> Reporter: Nils Breunese
>
> When SessionImporter#resolveUUIDConflict(parent, conflictingId, nodeInfo) is
> called and uuidBehavior is set to
> ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW an exception is thrown with a
> message saying that a node with the same UUID already exists. We have found
> that usually when this happens it would be very handy to know the path of the
> conflicting node. Right now, whenever this happens we need to attach a
> debugger to find the conflicting node. Could conflicting.getPath() be added
> to the message, so there is no need to attach a debugger to find that path?
--
This message was sent by Atlassian JIRA
(v6.1#6144)