Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
Installer Core 3.5.4, Installer Configuration Factory 1.0.14
-
None
Description
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.