felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Soto (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5549) Factory component fails to reactivate after config changes
Date Mon, 20 Feb 2017 13:53:44 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874553#comment-15874553

Alex Soto commented on FELIX-5549:

So you are saying this works as expected.

I find this behavior is very odd; it seems to go against the dynamism, which is probably the
main selling point of the framework. Components should come and go in a dynamic way, but in
this case, the component just goes away, and never comes back.  It is also very counter-intuitive,
since the other kind of component will be reactivated when its configuration changes, but
not this. To be clear,  I am only talking about the org.osgi.service.component.ComponentFactory,
which gets deactivated and never reactivated again.  I understand that instances of FactoryComp
will not be automatically reactivated, since it is flagged as factory component, and that
is fine.  My problem is that the Witheboard pattern is broken; a change of the configuration
stops the ComponentFactory, but I need it to be reactivated with the new configuration values,
not stopped.

On a different note, I do think factory components are useful, and I have designed my solution
based on this mechanism.  Are factory component going to be removed in a future release? 
If not, I think this should be fixed.  Unless there is a reason for this odd behavior, which
I don't see right now.   Do you know what is the rationale behind this behavior?

> 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

View raw message