Hi Tom, Am Dienstag, den 12.02.2008, 10:19 +0100 schrieb Tom Remoleur: > Hi Felix, > > Thanks you, it's a good idea to persist the good configuration directly in > the ManagedService, I can't completly apply your solution because my > application use an unique XML configuration file, but that isn't a > problem, I found how to do that cleanly.
Superb. > The last problem is about ConfigurationListeners that will received > ConfigurationEvent.CM_UPDATED even if the configuration failed to update. Yes, because this event just tells that the configuration data has been modified not that the ManagedService has accepted the modified configuration. > So I will create a new ConfigurationListener system with events > (UPDATE_SUCCESS, UPDATE_FAILED) send by my ManagedServices. > > With all these problems, I thinks that current OSGI configuration admin > specification is incomplete. Could OSGI Alliance be interested by these > feedbacks in order to do evolve the spec ? Yes, I thought the same. Because the spec only speaks of management agents being interested in failed updates to ManagedServices but do not elaborate on the details. What do others think about a potential extension to the Configuration Admin spec in our implementation which sends an event after calling the update method: The event would contain something like the PID of the ManagedService and optionally any update failure information from the update call ? Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
