You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Robert Munteanu (JIRA)" <ji...@apache.org> on 2014/05/20 14:48:38 UTC

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

    [ https://issues.apache.org/jira/browse/SLING-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003172#comment-14003172 ] 

Robert Munteanu commented on SLING-3583:
----------------------------------------

[~egli] - can you please attach an archive of the content structure? It's much faster than trying to re-create it myself

> 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)