Felix, Thanks for your quick response. Unfortunately, this first start situation will cause a pretty big error in our application. We understand that the component needs to be reactivated when there is a configuration change. What are your thoughts about suppressing this event when no configuration is found and a default one is created? Thanks, Jason
-----Original Message----- From: Felix Meschberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2008 1:24 AM To: [email protected] Subject: Re: ConfigAdmin Service Hi Jason, The situation is the following: SCR (the Declarative Services Runtime) activates a component and registers a ManagedService on behalf of the component. When the configuration admin services sees this ManagedService it has to provide the ManagedService with configuration (if existing) or null (if not existing). If the configuration is hitting the ManagedService SCR has to restart the component to provide the new configuration to the component. Even in the case there is no configuration at all. The configuration the component is receiving is merged from the configuration admin configuration and the properties from the service decalaration and a number of predefined configuration values. No, the problem is probably a "first" start situation, where the configuration admin has to provide a ManagedService with the information that there is no configuration at all. In this situation the SCR might be more intelligent and just not forward this event. In the case of the Configuration Admin really providing configuration data, we of course have to reactivate the component to provide the configuration. Hope this helps. Regards Felix Burmeister, Jason schrieb: > We are using Declarative Services. > > > > When we start up Felix it activates our bundle but then the bundle > immediately deactivates and activates again. It appears that the > ConfigAdmin service has detected a change in the configuration causing > the bundle to reactivate. It also appears that ConfigAdmin might be > creating a default configuration for each bundle consisting of the > service.pid and some other stuff. In simple test cases the behavior is > inconsistent. Maybe there is a race condition where activate() is > called before the configuration update. > > > > We get the following debug message: > > "Deactivating and Activating to reconfigure from configuration" > > > > Should the bundle reactivate when no configuration is supplied and a > default configuration is created? > > > > Thanks > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
