Hi, On 8/9/06, Nicolas <[EMAIL PROTECTED]> wrote:
What I don't understand is I find the code in the WorkspaceImporter in the protected NodeState resolveUUIDConflict method.Here is an excerpt: itemOps.checkRemoveNode(conflicting, BatchedItemOperations.CHECK_ACCESS | BatchedItemOperations.CHECK_LOCK | BatchedItemOperations.CHECK_VERSIONING | BatchedItemOperations.CHECK_CONSTRAINTS); // do remove conflicting (recursive) itemOps.removeNodeState(conflicting););
The problem with that is that we don't want to *remove* the root node, just replace all its unprotected content. As further discussed on IM, there are two other related issues. One is the fact that currently the code that handles REPLACE_EXISTING falls back to throwing a RepositoryException when handling the root node. This seems to be in line with allowed behaviour specified in JSR 170. Another fact is that currently rep:root is not mix:referenceable, so the root node doesn't expose the jcr:uuid property and thus there is no way to actually invoke the special jcr:root processing rules specified by JSR 170. So for now the best approach is to use a custom importer for the restore tool, but we might still want to consider making the root node referenceable and implementing the proposed jcr:root handling in import. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
