[jira] [Comment Edited] (SLING-7496) Factory config deleted with ConfigAdmin immediately after creation

2018-02-19 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler edited comment on SLING-7496 at 2/19/18 4:02 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, reverting to the 
config known to the installer, state = INSTALLED

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. So I think that test case 
is correct

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

[jira] [Comment Edited] (SLING-7496) Factory config deleted with ConfigAdmin immediately after creation

2018-02-19 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/SLING-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Comment Edited] (SLING-7496) Factory config deleted with ConfigAdmin immediately after creation

2018-02-19 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler edited comment on SLING-7496 at 2/19/18 2:19 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. 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?


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

So I think the test is actually correct and the state needs to switch from 
INSTALLED to IGNORED when a configuration installed through the installer is 
manually changed

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