[
https://issues.apache.org/jira/browse/SLING-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-4272.
-----------------------------------
> 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.6.0, Installer Configuration Factory
> 1.1.0
>
>
> 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)
