[
https://issues.apache.org/jira/browse/FELIX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883205#comment-15883205
]
Alex Soto commented on FELIX-5549:
----------------------------------
One of the behaviors that baffles me about the factory components is the
inconsistent registration/unregistration of the accompanying
_org.osgi.service.component.ComponentFactory_ service.
The _org.osgi.service.component.ComponentFactory_ service is not registered
(rightly) until all the Factory Component dependencies are resolved, but then,
when a configuration change is made, it is not unregistered. The framework
decides to deactivate the factory component (again, rightly), but leaves the
factory service behind. On the other hand, if the factory component becomes
unresolved due to a missing component dependency, the behavior is different,
the factory service is unregistered from the OSGi registry and the watchers are
notified. If the missing component dependency becomes active again, then
factory service is registered again and watchers notified. Why not treat both
conditions the same way? I mean, a change in the configuration should behave
like a dependency component is deactivated and activated, i.e., the factory
service should be unregistered, and registered, and watchers notified, exactly
the same behavior as with the dependency components.
This may not be a bug in the implementation but an odd design.
> Factory component fails to reactivate after config changes
> ----------------------------------------------------------
>
> Key: FELIX-5549
> URL: https://issues.apache.org/jira/browse/FELIX-5549
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Environment: Karaf 4.0.8
> Reporter: Alex Soto
>
> A factory component fails to reactive after the configuration changes.
> Initially, the component initializes normally. After it is in Active state,
> the configuration referenced by the component _configurationPid_ changes,
> which causes the component to not activate again.
> A minimal application demonstrating this behavior is available here:
> https://github.com/lexsoto/blueprint-ds-config-reload
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
