Hi Felix, (1) I'll think about whether there's a way to use the revision counter only if present. Unless I hear of a good reason otherwise I think leaving things as they are is probably a good idea.
(2) My idea about the MS/ MSF (after some more thinking) would be to (a) register just one MS and one MSF and keep changing the pids in the ServiceRegistration to reflect the currently enabled components. ConfigAdmin should be able to use this to track what it should do. (b) Do an initial query and use a configuration listener to keep track of the pids and factorypids CA knows about to decide whether a configuration PID is singleton or factory. Since CA has to deliver configuration events on a single thread (per component) in order, and internally it can do appropriate locking, I think that in fact using MS/MSF would result in correct behavior, with no duplicates between initial configuration and any "later" events. But this solution is definitely more complicated. many thanks! david jencks On Feb 24, 2013, at 5:37 AM, Felix Meschberger <[email protected]> wrote: > Hi David, > > Am 23.02.2013 um 23:42 schrieb David Jencks: > >> There's a race condition in DS between registering a new component holder >> for existing configuration and processing configuration events. Before >> FELIX-3912 it was possible to completely miss a configuration for a new >> component holder if the configuration arrived between the query for existing >> configurations and the registration of the holder for configuration updates. >> I switched the order, and now there's a chance a configuration update will >> be applied twice. (even after my second commit on this) >> >> Is this a problem? > > I think not. It is probably better to have a chance of double configuration > than to have a risk of missing configuration. > > The latest Config Admin spec introduces a revision counter to the > Configuration object. DS could check that -- but this would require the > latest Config Admin spec. Not sure, whether this would be worth it. > >> >> I think a solution would be to register a ManagedService or >> ManagedServiceFactory for each component holder, since then the initial >> configuration and all updates would occur on the same thread. This seems >> like a lot of services…. > > Yes, and it does not help. (a) MS and MSF are also called asynchronously and > (b) to support both factory and singleton configurations (whatever is > present) both MS and MSF would be required. Even more services. > >> >> I haven't thought much but I think to distinguish between MS and MSF we need >> to query the initial set and look for events to determine whether there's a >> factoryPID or just PID and use that to decide. > > If there is no initial configuration you don't have anything to decide on ... > >> >> Thoughts? Any other ideas? > > I think it suffices it to register before checking and risk "double" > configuration in edge cases. > > Regards > Felix > > >> >> many thanks >> david jencks >> > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > >
