Can you check if this still happens with trunk? I recently fixed https://issues.apache.org/jira/browse/FELIX-5194 <https://issues.apache.org/jira/browse/FELIX-5194> which is a race condition on component startup between querying config admin and getting the initial configuration event.
david jencks > On Mar 9, 2016, at 6:08 AM, Jens Offenbach <[email protected]> wrote: > > It has something to do with the TargetedPID. The modified or deactivate > method gets called when oldTargetedPID is null. Why is it sometimes null? Is > it possible that the component got instantiated and configured, but has a > TargetedPID of null? > > ConfigurationSupport.java (Line 338): > TargetedPID oldTargetedPID = componentHolder.getConfigurationTargetedPID(pid, > factoryPid); > if ( targetedPid.equals(oldTargetedPID)) > ... > } > > > Gesendet: Mittwoch, 09. März 2016 um 14:44 Uhr > Von: "Carsten Ziegeler" <[email protected]> > An: [email protected] > Betreff: Re: SCR: Sometimes component gets instantiated twice > Jens Offenbach wrote >> Now, I am confused... But I am using 'configuration-policy="require"'. This >> should force SCR to activate my component only when there is a valid >> configuration. >> > > Your configuration is changed, config admin fires a configuration > changed event, which in turn reactivates your component. It might be the > same configuration, but as someone updated the config, config admin > needs to send out the event. > > If you don't implement modified, your component is deactivated and then > activated. Otherwise modified is called. > > As you have require as the configuration policy, the only way to avoid > this is to make sure that the configuration is not updated in config admin. > > So this is not an SCR problem, everything behaves as expected. It looks > rather like a provisioning problem to me. > > In general, OSGi is dynamic, so your component should behave properly > and expect this "restarting" through a configuration change. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] > > --------------------------------------------------------------------- > 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] >
