[jira] [Commented] (SLING-4272) Issues in handling of configurations wrt update handling and write back

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

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

Carsten Ziegeler commented on SLING-4272:
-----------------------------------------

Fixed 1. in rev 1648985 by keeping track of the changes started by the installer and checking these when a configuration event occurs. This fixes also the handling of SLING-4271. I've added some test cases for both configurations and factory configurations.

> Issues in handling of configurations wrt update handling and write back
> -----------------------------------------------------------------------
>
>                 Key: SLING-4272
>                 URL: https://issues.apache.org/jira/browse/SLING-4272
>             Project: Sling
>          Issue Type: Bug
>          Components: Installer
>    Affects Versions: Installer Core 3.5.4, Installer Configuration Factory 1.0.14
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>            Priority: Critical
>             Fix For: Installer Core 3.5.6, Installer Configuration Factory 1.0.16
>
>
> There are several issues with handling configurations:
> 1. If a configuration resource is modified or deleted, a task is created performing the operation. This results in an event from config admin which is then handled by the udpate handler and in turn might create new tasks. There is some logic to detect this situation but this is incomplete; Implementing SLING-4271 revealed such a case.
> The correct behaviour would be to detect this situation within the configuration factory and do not call the update handler when a configuration event occurs.
> 2. If a configuration change is triggered through config admin, this results in a configuration event picked up by the configuration factory. The factory calls the update handler which does some magic to update it's state. We have to carefully check that this call is just updating state but not creating new tasks again. The write back functionality is the only function to be called.
> 3. The configuration factory is mixing update handling and persistence: right now if a configuration change should not be persisted it's not called the update handler at all. It would be better to call the update handler and let the handler decide whether to persists the resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)