jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: can't Import a system view using ImportXML
Date Wed, 09 Aug 2006 22:25:20 GMT
Hi,

On 8/9/06, Nicolas <ntoper@gmail.com> 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/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message