Filtering is usually done before you get all services - so this works perfectly well with service properties. Right now, the main use case we have is registering the services as mbeans, followed by showing the results in the web console - and this can easily use service references or the mbeans.
Carsten 2013/8/14 Felix Meschberger <fmesc...@adobe.com> > 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 <cziege...@apache.org> > 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 > > -- Carsten Ziegeler cziege...@apache.org
