[jira] [Created] (SLING-3583) children of folder, containing files besides .content.xml, will get deleted on content-sync

["Stefan Egli (JIRA)" <ji...@apache.org>]

Stefan Egli created SLING-3583:
----------------------------------

             Summary: children of folder, containing files besides .content.xml, will get deleted on content-sync
                 Key: SLING-3583
                 URL: https://issues.apache.org/jira/browse/SLING-3583
             Project: Sling
          Issue Type: Bug
          Components: IDE
            Reporter: Stefan Egli
            Assignee: Robert Munteanu
             Fix For: Sling Eclipse IDE 1.0.0


In slingclipse, when content is synched to a launchpad-server, children of certain folders are immediately deleted after creation.

Details:
 * consider a sling-content project which contains e.g the following structure (node names of children describe their primary type)
{code}
someparent
├── osgiconfig
├── ntfolder
├── ntunstructured
│   └── childofntunstructured
└── slingfolder
    └── childofslingfolder
{code}

* The SlingLaunchpadBehavior.publishContentModule, which is in charge of updating the launchpad with changes in the eclipse-filesystem, goes through the list of files (Let's assume an initial publish for simplicity reason).

* It so happens, that the order of iteration is in such a way, that the someparent/.content.xml is handled last - after the other children have properly been synched with the server.

* Upon handling of someparent/.content.xml, SlingLaunchpadBehavior.addFileCommand is executed, and in there, serializationManager.readSerializationData() (or more precisely in VltSerializationManager.readSerializationData()) returns the *parent of the .content.xml file*, namely the 'someparent' node.

* With that, in turn, the AddOrUpdateNodeCommand.processDeletedNodes() claims that the someparent(ex ./.content.xml) has no children, hence deletes all existing ones from the server.

[~rombert], assigning this to you as you're more familiar with the code in that area. I'm uncertain if the real bug is in the readSerializationData or in the AddOrUpdateNodeCommand.. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)