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:[EMAIL PROTECTED] > Sent: Monday, October 16, 2006 3:27 PM > To: [email protected] > 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) < > [EMAIL PROTECTED]> > 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.
