[
https://issues.apache.org/jira/browse/FELIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269562#comment-15269562
]
David Jencks commented on FELIX-5248:
-------------------------------------
I think this can be fixed. I suggest we get Guillaume's refactoring in first.
A test would be an integration test, which is currently mixed into the same
test folder as unit tests but run separately. It should be fairly
straightforward to write a component that throws an exception in activate
depending on a config property, and to change the config back and forth a few
times to see what happens.
It's less clear to me how to deal with the situation where other components
have a reference to the service with the intermittent problem. Maybe we could
track "failed lookup" links and clear them on any other service change
(certainly unregistration).
> SCR does not reactivate a failed component after a configuration update
> -----------------------------------------------------------------------
>
> Key: FELIX-5248
> URL: https://issues.apache.org/jira/browse/FELIX-5248
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.0.4
> Reporter: Timothy Ward
> Priority: Blocker
>
> A configurable SCR component may fail to activate by throwing an exception if
> the factory configuration contains bad values. If the factory configuration
> for that component is then updated SCR should attempt to recreate and
> activate the component. Instead the component sits in the "satisfied" state
> forever, and updates to the factory configuration are ignored.
> This makes it impossible to "fix" a mistaken configuration without deleting
> and recreating it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
