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.

View raw message