Sorry to post everything in several mail. Actually the error in importing
from the sysView is in this validation code (in ItemValidator):
// mandatory child nodes
       NodeDef[] cnda = entPrimaryAndMixins.getMandatoryNodeDefs();
       for (int i = 0; i < cnda.length; i++) {
           NodeDef cnd = cnda[i];
           if (!nodeState.hasChildNodeEntry(cnd.getName())) {
               String msg = safeGetJCRPath(nodeState.getNodeId())
                       + ": mandatory child node " + cnd.getName()
                       + " does not exist";
               log.debug(msg);
               throw new ConstraintViolationException(msg);
           }
       }
   }

The issue here is {internal}root (is there a difference with jcr:root?)
doesn't have the mandatory child nodes... Which is true according to the
sysView XML.

For reference, the exception I got is:
Exception in thread "main" javax.jcr.nodetype.ConstraintViolationException:
/jcr:root: mandatory child node {http://www.jcp.org/jcr/1.0}system does not
exist
   at org.apache.jackrabbit.core.ItemValidator.validate(ItemValidator.java
:144)
   at org.apache.jackrabbit.core.xml.WorkspaceImporter.endNode(
WorkspaceImporter.java:538)
   at org.apache.jackrabbit.core.xml.SysViewImportHandler.processNode(
SysViewImportHandler.java:95)
   at org.apache.jackrabbit.core.xml.SysViewImportHandler.endElement(
SysViewImportHandler.java:233)
   at org.apache.jackrabbit.core.xml.ImportHandler.endElement(
ImportHandler.java:210)
And so on...

I would propose to keep "my quick hack", since if I understand things
correctly we *do* have to skip the root node import.

What do you think?
Nicolas
On 8/9/06, Nicolas <[EMAIL PROTECTED]> wrote:

Jukka,

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););

Nicolas

On 8/9/06, Jukka Zitting < [EMAIL PROTECTED]> wrote:

> Hi,
>
> On 8/9/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote:
> > we should IMO support IMPORT_UUID_COLLISION_REPLACE_EXISTING
> > for jcr:root properly rather than doing shortterm hacks.
>
> Agreed. I think the correct implementation would be something like the
> following:
>
>     if (REPLACE_EXISTING and jcr:uuid matches an existing node) {
>         find the target node
>         foreach (target property and child node) {
>             if (!protected) {
>                 remove();
>             }
>         }
>         import to target
>     }
>
> This would also take care of the jcr:system case quite naturally.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
> Software craftsmanship, JCR consulting, and Java development
>



--
a+

Nico
my blog! http://www.deviant-abstraction.net !!




--
a+
Nico
my blog! http://www.deviant-abstraction.net !!

Reply via email to