[
https://issues.apache.org/jira/browse/SLING-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369155#comment-16369155
]
Carsten Ziegeler edited comment on SLING-7496 at 2/19/18 3:40 PM:
------------------------------------------------------------------
[~bosschaert] I just looked at what
ConfigInstallTest#testInstallUpdateRemoveConfigFactory does. As the name says
it installs a configuration through the installer, updates the config through
CM and then removes the config through CM.
Now the desired states are:
* config installed through installer. state = INSTALLED
* config updated through CM - manual intervention detected, state = IGNORED
* config removed through CM - manual intervention detected, state = IGNORED
The state needs to switch from INSTALLED to IGNORED when a configuration
installed through the installer is manually changed. So I think that test case
is correct
was (Author: cziegeler):
[~bosschaert] I just looked at what
ConfigInstallTest#testInstallUpdateRemoveConfigFactory does. As the name says
it installs a configuration through the installer, updates the config through
CM and then removes the config through CM.
Now the desired states are:
* config installed through installer. state = INSTALLED
* config updated through CM - manual intervention detected, state = IGNORED
* config removed through CM - manual intervention detected, state = IGNORED
The state needs to switch from INSTALLED to IGNORED when a configuration
installed through the installer is manually changed. Now the key word hey is
"changed", the test is actually not changing the configuration just pushing the
same set of properties again. In that case, yes, the state should stay in
INSTALLED. Could you please enhance the test, that it actually changes the
config afterwards and verifies that the state then is IGNORED?
> Factory config deleted with ConfigAdmin immediately after creation
> ------------------------------------------------------------------
>
> Key: SLING-7496
> URL: https://issues.apache.org/jira/browse/SLING-7496
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: Installer Configuration Factory 1.1.2
> Reporter: David Bosschaert
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: Installer Configuration Factory 1.2.0
>
>
> In some cases when a factory configuration is created using the OSGi
> ConfigAdmin API, the configuration gets a call to {{delete()}} immediately
> when {{update()}} on the configuration is called.
>
> The issue comes down to the fact that the factory prefix is prepended twice
> to the configuration at some point in the installer, which is then assigned
> to the resource {{entityId}}. This mismatch causes the initial configuration
> to receive a delete callback as the system thinks it's no longer there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
