jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daglian, Michael \(IT\)" <Michael.Dagl...@morganstanley.com>
Subject RE: Using importXML with existing content
Date Mon, 16 Oct 2006 21:15:27 GMT
Hi Nico, 

Thanks for the detailed explanation! I believe the line number may be
due to an older version of Jackrabbit being used (I got the trace from a
colleague) so my apologies for sending you mixed information. I believe
your assessment of the situation is correct: /test/foo has some children
that do not allow same name siblings and are not autocreated. I also
missed the line in the spec but I believe that it does validate the
behavior I am seeing. All that being said, what is the workaround you
suggest, assuming your description of the scenario?

Best Regards,

-- Mike 

> -----Original Message-----
> From: Nicolas [mailto:ntoper@gmail.com] 
> Sent: Monday, October 16, 2006 3:27 PM
> To: users@jackrabbit.apache.org
> Subject: Re: Using importXML with existing content
> 
> 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
> >
>
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to
waive confidentiality or privilege. Use of this email is prohibited when received in error.

Mime
View raw message