Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 23 Mar 2017 15:05:42 +0000 (UTC)
From: "Alex Soto (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.13043368.1487189565000.102300.1490281542514@Atlassian.JIRA>
In-Reply-To: <JIRA.13043368.1487189565000@Atlassian.JIRA>
References: <JIRA.13043368.1487189565000@Atlassian.JIRA> <JIRA.13043368.1487189565443@jira-lw-us.apache.org>
Subject: [jira] [Commented] (FELIX-5549) Factory component fails to
 reactivate after config changes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 23 Mar 2017 15:05:49 -0000


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

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

bq. I think there may be a different bug, which I suspect is a mistake in the spec. The second condition specifies using the component properties from the component description, i.e. the xml before merging with any configurations, whereas the implementation IIRC uses the properties from merging the xml with configurations. I suspect this is an historical error from not updating the part of the spec dealing with factory components when configuration from config admin was introduced.

Are you agreeing that the second condition should be amended to include the configuration? If so, would this mean that the Component Factory Service would need to be registered/unregistered as a response to the configuration changes? Even if only for the case of REQUIRED policy, this would help me a great deal to react to this condition.


> 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)