jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: can't Import a system view using ImportXML
Date Wed, 09 Aug 2006 16:16:49 GMT
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 <ntoper@gmail.com> 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 < jukka.zitting@gmail.com> wrote:
>
> > Hi,
> >
> > On 8/9/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> 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/ - info@yukatan.fi
> > 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 !!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message