Return-Path: X-Original-To: apmail-felix-dev-archive@www.apache.org Delivered-To: apmail-felix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9282217C7E for ; Sat, 11 Apr 2015 13:13:12 +0000 (UTC) Received: (qmail 42018 invoked by uid 500); 11 Apr 2015 13:13:12 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 41951 invoked by uid 500); 11 Apr 2015 13:13:12 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 41939 invoked by uid 99); 11 Apr 2015 13:13:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Apr 2015 13:13:12 +0000 Date: Sat, 11 Apr 2015 13:13:12 +0000 (UTC) From: "Simon Chemouil (JIRA)" To: dev@felix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491019#comment-14491019 ] Simon Chemouil commented on FELIX-4851: --------------------------------------- Oh thanks a lot. We're facing the same problem that has been plaguing us for some time, and I was thinking to try to find exactly what's happening this afternoon, but you just made that useless :). My workaround so far has been to call configAdmin.getConfiguration(configPid, null).update(properties); after all bundles are in the ACTIVE state, which is very ugly. I believe this fix alone, if it's approved, warrants a new release! I might as well report that Felix SCR's "scr:info" Gogo command is outputing wrong info when the problem happens; it seems it has no way to tell a component is unsatisfied because the required configuration was not provided, an instead the first required service reference is stated as unsatisfied, even though the service is indeed provided and used elsewhere in the same bundle. > ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE > ------------------------------------------------------------------------------------------------------------------------------ > > Key: FELIX-4851 > URL: https://issues.apache.org/jira/browse/FELIX-4851 > Project: Felix > Issue Type: Bug > Components: Configuration Admin > Affects Versions: configadmin-1.8.2 > Reporter: Jens Offenbach > Fix For: configadmin-1.8.4 > > > I am facing a serious problem with the Felix ConfigAdmin in combination with Felix SCR. Let us assume that the SCR bundle becomes activated at last and activates a component that creates a configuration which itself is a precondition for the instantiation of another component (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not deliver the configuration update event to SCR, although SCR has registered a ConfigurationListener in the OSGi Service Registry. > The problem is caused by line 2029 of the class ConfigurationManager (Version: 1.8.3-SNAPSHOT): > {code} > if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE && this.listeners[serviceIndex] != null ) > {code} > In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE state directly after all available components have been activated. Because of missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able to activate all those components whose preconditions are actually fulfilled. The problem does not occur in combination with the Equinox ConfigAdmin, which does not make the problematic bundle state check. > I highly recommend removing the bundle state check and change line 2029 into: > {code} > if ( this.listeners[serviceIndex] != null ). > {code} > It is up to the developer to decide, in which bundle state configuration events are considered to be important or not. In the SCR scenario, the developers rely on the fact that configuration events are delivered independently of their bundle state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)