[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
[ https://issues.apache.org/jira/browse/FELIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15327785#comment-15327785 ] David Jencks commented on FELIX-5248: - I added a test that while simpler than your situation I thought would include the important parts, and currently it appears to pass. Could you see if your original case now works properly as well, and if not see if you can figure out what is missing in my test? > 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)
[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
[ 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)
[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
[ https://issues.apache.org/jira/browse/FELIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269493#comment-15269493 ] Timothy Ward commented on FELIX-5248: - Hi David, The component is immediate and has a configuration policy of required. It has one static reference to a service which is satisfied, an activate method which takes a bundle context, a type safe configuration object, and a map of the raw configuration. It also has a deactivate method which takes no arguments. The failure flow is as follows: 1. The component's bundle is started and the referenced service is available. The configuration requirement correctly prevents activation of any component instances. 2. A factory configuration is created for the correct factory pid with some config properties. Occasionally one of the config properties is malformed, which the component instance detects, throwing an exception from the activate method. This correctly prevents that component instance from starting when the config is bad. 3. The factory configuration is then updated by the user to correct the malformed config property. At this point I do not get the behaviour I expect. I expect a component instance to be activated with the updated configuration. Instead the component sits there, ignoring the configuration update. If at this point I disable and enable the component then everything works fine, but I don't want to do that as it will disable all of the other instances created by other factory configurations. It also works if I delete the old config and create a new config, but I don't want to do that either because it's an extra set of steps for the user. I don't think that what I'm asking for is illogical, although I can't find a line in the specification which says that it must work. I hope this helps. I've tried looking through the felix SCR unit tests, but at the moment I'm not entirely sure how I would write a failing test for this behaviour. Tim > 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)
[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
[ https://issues.apache.org/jira/browse/FELIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269101#comment-15269101 ] David Jencks commented on FELIX-5248: - Can you provide more information about the scenario you are talking about? If not a test case, at least some indication of how many components, any references, and the immediate setting. Also more information about the sequence of events you'd like to have happen. For instance, providing the factory configuration to a component that provides a service is going to register the service. If the component isn't immediate, then we'll try to create the service when someone asks for it. If the configuration changes, someone has to ask for it again in order for it to get created. If you are using the lookup strategy or the event strategy with ServiceReference, you can try again whenever you want. > 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)
