Hi, Am 25.02.2013 um 05:42 schrieb David Jencks:
> I attached a patch to 3915 with an implementation that should use the R5 > changeCount if available, and does something like the last commit if not. I > haven't found a R5 compendium in maven yet, so I'm using reflection. Hoping > to update soon. WDYT? The enterprise JAR is available at version 5.0.0 from Maven and provides the updated Configuration Admin 1.5 API. Just make sure to not require Configuration Admin 1.5 for deployment of SCR: It should gracefully fall back to duplicate configuration delivery if cm<1.5 and Configuration.getChangeCount() is not available. > > The MS/MSF approach won't work in general in R5 because of targetPids. I'm > going to look at implementing support for these and the location changed > event. Great, that is a big missing thing (and issues exist for these, IIRC). Thanks alot. Regards Felix > > thanks > david jencks > > On Feb 24, 2013, at 11:00 AM, David Jencks <[email protected]> wrote: > >> 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 >>> >>> >>> >>> >>> >>> >>> >> > -- Felix Meschberger | Principal Scientist | Adobe
