On Feb 13, 2008 2:51 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > 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
I think that is a good idea. Maybe bring up the issue on osgi-dev? regards, Karl > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
