[
https://issues.apache.org/jira/browse/FELIX-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved FELIX-4237.
---------------------------------
Resolution: Cannot Reproduce
Assignee: David Jencks
Fix Version/s: scr-2.0.4
I can't find the relevant parts of the test case any more, namely the exact
component configurations and code. The most obvious reason this is happening
is that D1 doesn't have a modified method, so it has to be recycled. This is
going to cause anything with a mandatory dependency on it to recycle.
I would guess the effect of when you get the service from the service tracker
means the components aren't immediate and unless you get the service promptly
it's deactivated since there are no references to it.
> Updating a configuration may deactivate/active component multiple times
> -----------------------------------------------------------------------
>
> Key: FELIX-4237
> URL: https://issues.apache.org/jira/browse/FELIX-4237
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.2
> Reporter: Thomas Diesler
> Assignee: David Jencks
> Fix For: scr-2.0.4
>
>
> * ServiceD has a mandatory unary reference to ServiceD1
> * ServiceD1 is backed by a configuration in ConfigurationAdmin (1.6.0)
> * Activate the services with no configuration
> * Create and update the configuration for ServiceD1
> The observed behaviour is
> * ServiceD gets deactivated
> * ServiceD1 gets deactivated
> * New instance of ServiceD1 is constructed and activated with the
> configuration
> * ServiceD1 is bound to to a new instance of ServiceD and ServiceD gets
> activated
> following this ServiceD1 may get deactivated again causing the above sequence
> to get repeated.
> In a large dependency graph this would deactivate/activate all components in
> the graph. Component activation may not be cheap and should not be done
> repeatedly with the same configuration passed in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
