Thank you for the detailed explanation. It was very helpful.
Tim Moloney The reasonable man adapts himself to MRSL the world; the unreasonable one persists 2015 Cattlemen Road in trying to adapt the world to himself. Sarasota, FL 34232 Therefore all progress depends on the (941) 377-6775 x208 unreasonable man. - George Bernard Shaw > -----Original Message----- > From: Felix Meschberger [mailto:[email protected]] > Sent: Wednesday, May 13, 2009 16:36 > To: [email protected] > Subject: Re: How are configurations received from ConfigAdmin > service expected to be used? > > Hi Tim, > > Moloney, Tim M schrieb: > > I understand that the ManagedService has to handle the > missing number > > property. What is the expected way for this to happen? > > This is the ManagedService's task to handle. There is AFAICT no > specified requierement. The specification just says, that what ever > properties are set in the Configuration.update(Dictionary) call are > forwarded to the ManagedService.update(Dictionary) method. > > The Configuration admin does not care about the contents of the > Dictionary except for the three properties I mentioned earlier. > > > > > Is each configuration considered to be complete and > self-contained, so > > the answer below would be number:7? If this is the case, then the > > ManagedService is reset to the default configuration before > the passed > > configuration is applied. > > The question is "who defines completeness". The ConfigurationAdmin > service has no knowledge about the completeness. > > In fact it is really simple: The ManagedService gets the > dictionary and > checks for the "number" property. If the property does not > exist (or is > of the wrong type or out of range or otherwise invalied) the > ManagedService might apply a default value. > > Or, alternatively, the ManagedService.update(Dictionary) method may > throw a ConfigurationException if it is not happy with the > configuration. The ConfigurationAdmin service then knows, that the > ManagedService has no accepted the configuration. > > > > > Is each configuration considered an update to the current > configuration, > > so the answer below would be number:1? If this is the > case, then the > > ManagedService is NOT reset before the passed configuration > is applied. > > No, each call to the update method contains the complete configuration > dictionary. There is no such thing as a differiential or > incremental update. > > > > > At first, I thought it was the latter (inferred by the name of the > > update method). However, the few examples I've seen appear > to implement > > the former. Looking at the source code also suggests the > former since > > Configuration.update() calls > Configuration.configureFromPersistence() > > and Configuration.update(Dictionary) simply replaces the > Dictionary used > > for persistence. > > The point is, that the Configuration.update() method updates the > configuration object with data from the persistent storage for the > administration agent to have up-to-date information in hand. > > The Configuration.update(Dictionary) method is called by the > administratrive agent to replace the existing configuration with a new > configuration. This replacement takes place in the order: store in the > persistent storage and then (asynchronously) update the registered > ManagedService (if any). > > Let me add a final comment about "ManagedService is reset": A > ManagedService is not reset. Just the update method gets > called as follows: > > * When the service is first registered, the method is called with > existing configuration or null if there is no configuration yet > > * On each update of the configuration as per > Configuration.update(Dictionary) > > * When a configuration is deleted by Configuration.delete the > update method is called with null > > Hope this helps. > > Regards > Felix > > > > > > > Tim Moloney The reasonable man > adapts himself > > to > > ManTech Real-time Systems Laboratory the world; the > unreasonable one > > persists > > 2015 Cattlemen Road in trying to adapt > the world to > > himself. > > Sarasota, FL 34232 Therefore all > progress depends on > > the > > (941) 377-6775 x208 unreasonable man. - George > > Bernard Shaw > > > > > >> -----Original Message----- > >> From: Felix Meschberger [mailto:[email protected]] > >> Sent: Wednesday, May 13, 2009 14:17 > >> To: [email protected] > >> Subject: Re: How are configurations received from ConfigAdmin > >> service expected to be used? > >> > >> Hi Tim, > >> > >> Moloney, Tim M schrieb: > >>> I've starting working with the ConfigurationAdmin service > >> and I need to > >>> know how a configuration that a ManagedService recieves is > >> expected to > >>> be used. > >>> Is the received Dictionary an augmentation of the current > >> configuration > >>> or is it a complete configuration. For example, > >>> > >>> ManagedService Foo (default color: blue, default number: 7) > >>> > >>> Foo receives (color: red, number: 1) and is set to (color: > >> red, number: > >>> 1). > >>> > >>> If Foo then receives (color: yellow) should Foo's configuration be > >>> (color: yellow, number: 1) or (color: yellow, number: 7)? > >> The ManagedService.update method receives the exact contents of the > >> dictionary ues by the managemant agent for calling the > >> Configuration.update(Dictionary) method with three additional > >> properties > >> managed by the ConfigurationAdmin service (service.pid, > >> service.factoryPid, service.bundleLocation). > >> > >> So when the configuraiton is updated with just > (color:yellow), the Foo > >> service has to cope with the missing "number" property. > >> > >> Hope this helps. > >> > >> Regards > >> Felix > >>> Thanks. > >>> > >>> > >>> Tim Moloney The reasonable man adapts himself to > >>> MRSL the world; the unreasonable > one persists > >>> 2015 Cattlemen Road in trying to adapt the world > to himself. > >>> Sarasota, FL 34232 Therefore all progress depends on the > >>> (941) 377-6775 x208 unreasonable man. - George > Bernard Shaw > >>> > >>> > >> > --------------------------------------------------------------------- > >> 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] > > > > > > --------------------------------------------------------------------- > 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]
