jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: Using importXML with existing content
Date Mon, 16 Oct 2006 19:27:03 GMT
Michael,

Actually it do both. This has to do with the node creation system: if you
create a node, its children set on autocreate will be created with the node
and children nodes will not be recreated. The UC you have is supposed to be
handled by this version and my refactoring takes care of it too (the issue
with this class is it is really hard to understand).

The exception is on l 405 according to your stack trace. But the current
version of the importer cannot raise an exception at this line (it is a
commentary). I don't see any other  ItemExistsException than the one I have
sent you in this class.

Since you are not using the flag
ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW, it can only comes from here
unless you are using an older version of Jackrabbit. Besides, the
resolveUUIDConflict method is called only from l 465 so the flag is not used
yet.

Rereading the code, I understand what is happening. Please confirm those
assertions:

- /test/foo has some children
- as you said, allowSameNameSiblings is set to false
- as you said, autoCreate is set to false

Now the JCR specs states (p 226):
"An ItemExistsException will be thrown if the top-
most element of the incoming XML would deserialize
to a node with the same name as an existing child of
parentAbsPath and that child does not allow same-
name siblings."

(NB parentAbsPath is the string parameter in importXML method)

Is this what happens to you?

If yes, we will find a workaround :)

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


On 10/16/06, Daglian, Michael (IT) < Michael.Daglian@morganstanley.com>
wrote:
>
> Hi Nicolas,
>
> Pardon if I am mistaken, but doesn't the check there examine the
> definition of the conflicting child node as opposed to any of its
> properties? Regardless, the nodes themselves are not autocreated
> children, have no autocreated properties, and do not allow for
> same-named siblings - thus the exception occurs. Not quite sure if
> there's a way round this with the existing importer. Does your
> refactored importer allow for this use case? Again, thanks for all your
> help.
>
> Best Regards,
>
> -- Mike
>

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