Hi I think it all depends on who the primary consumer of the data is ...
In any case, having a generic getInfos() method does not help much if the infos really help identify the HealthCheck service. If the data -- like name, description, and tags -- are usefull in a reporting context, it might make sense to expose those as explicit API in the service. Those properties, that are used select service -- presumably the tags -- should be exposed as service registration properties. This may result in some properties to be exposed twice: This does not sounds nice, but maybe it is still better than to force all non-OSGi users to cope with a ServiceReference or to require getting service objects just to be able to filter on tags. Regards Felix Am 14.08.2013 um 10:16 schrieb Bertrand Delacretaz: > Hi Carsten, > > On Tue, Aug 13, 2013 at 8:27 PM, Carsten Ziegeler <[email protected]> > wrote: >> ...we briefly discussed this during the refactoring and I think we agreed :) >> that the current properties (for which constants are defined) should >> actually be service registration properties.... > > Not sure what you mean...adding getters for these properties? > > Having HealthCheck.getName(), HealthCheck.getTags() etc. would indeed > allow for removing the getInfo() method which is good. > > If that's what you mean I can make the changes later today, and get > rid of the Constants class as well. > > -Bertrand
