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 Wed, 22 Mar 2017 17:31:41 GMT

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

Alex Soto commented on FELIX-5549:
----------------------------------

OK,  maybe I am.  The true is, that as a user, I have been very confused by the inconsistent
behavior. I am relatively new to this, and I apologize for the confusion.

Yes, the conditions as documented, do not match the behavior, but fixing the documentation
alone will not be sufficient.

The fact that a client of the Factory component (in my case Booter) cannot react to the full
component life cycle is a major flaw, and my specific problem.  If the Factory Component is
deactivated due to configuration change, its clients are unaware and still hold and use a
reference to a component instance, without any way of knowing that it has been deactivated.
 This contrasts with to what happens with references, i.e., the Component  Factory Service
is unregistered/registered when references become unresolved/resolved, and the Booter is therefore
notified, and it can discard the component instance reference correctly.

I have a workaround (using modified) but then I need to use thread synchronization, to protect
members in case they are modified concurrently, which is not as clean as activation/deactivation.



> 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
>            Assignee: David Jencks
>
> 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)

Mime
View raw message