You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2013/08/13 20:27:18 UTC
[HC] Use service registration properties
Hi,
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.
Therefore I suggest to move the constants into the HC interface class and
then we can also remove the getInfo() method and clarify the contract
(which service props are required, what default values are used etc.)
In addition, the jmx bridge can then get HC services on demand but already
register the mbeans without getting the service.
If no one objects I'll create an issue for this and do the changes.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [HC] Use service registration properties
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 14, 2013 at 12:36 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I don't see any use case where it's not possible to have a service
> reference - and tools could just query the mbeans as an alternative...
Going via MBeans complicates things, and HC MBeans are optional
anyway, they're only active if the org.apache.sling.hc.jmx bundle is
active.
But I agree with you that it should be possible to have a service
reference in all cases where you need the HC service properties, so
feel free to do the changes as you suggest.
To check that you didn't break anything, the full build of
contrib/extensions/healthcheck should work, and both the webconsole
and JMX access should show all health checks as now, including their
name MBean name where useful and tags.
-Bertrand
Re: [HC] Use service registration properties
Posted by Carsten Ziegeler <cz...@apache.org>.
I don't see any use case where it's not possible to have a service
reference - and tools could just query the mbeans as an alternative
Carsten
2013/8/14 Felix Meschberger <fm...@adobe.com>
> Hi
>
> Am 14.08.2013 um 11:37 schrieb Bertrand Delacretaz:
>
> > On Wed, Aug 14, 2013 at 11:33 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> >> ...I mean not having these at all :) and just have them as service
> >> properties. Filtering services based on the tags can be done using the
> >> filter expression based on service properties and registering the
> checks as
> >> mbeans works this way as well...
> >
> > Ok, that's how it's done now.
> >
> >> Do we have other use cases ?
> >
> > We need some of these values (HC name and tags at least) in the
> > webconsole and MBeans when we output a Result. We usually don't have a
> > ServiceReference there, just HealthCheck, so it's much more convenient
> > to be able to access that info from a HealthCheck.
>
> Yet: for the MBean the Health Check controller getting the HealthCheck
> services and registering MBeans on behalf of them could as well leverage
> the ServiceReference properties to setup the MBean's objectname properties
> or Attributes. I would assume the actual MBean registered will be a
> proxy/wrapper to the HealthCheck service implementing the appropriate MBean
> interface and embedding the ServiceReference and HealthCheck objects, or so.
>
> As for the Web Console: This is one of the reporting tools, I had in mind.
> If the WebConsole directly accesses the services through the Service
> Registry, it will also have the ServiceReference in hand ...
>
> But still, there may be report tooling not able to cope with
> ServiceReferences ?
>
> Regards
> Felix
--
Carsten Ziegeler
cziegeler@apache.org
Re: [HC] Use service registration properties
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 14.08.2013 um 11:37 schrieb Bertrand Delacretaz:
> On Wed, Aug 14, 2013 at 11:33 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I mean not having these at all :) and just have them as service
>> properties. Filtering services based on the tags can be done using the
>> filter expression based on service properties and registering the checks as
>> mbeans works this way as well...
>
> Ok, that's how it's done now.
>
>> Do we have other use cases ?
>
> We need some of these values (HC name and tags at least) in the
> webconsole and MBeans when we output a Result. We usually don't have a
> ServiceReference there, just HealthCheck, so it's much more convenient
> to be able to access that info from a HealthCheck.
Yet: for the MBean the Health Check controller getting the HealthCheck services and registering MBeans on behalf of them could as well leverage the ServiceReference properties to setup the MBean's objectname properties or Attributes. I would assume the actual MBean registered will be a proxy/wrapper to the HealthCheck service implementing the appropriate MBean interface and embedding the ServiceReference and HealthCheck objects, or so.
As for the Web Console: This is one of the reporting tools, I had in mind. If the WebConsole directly accesses the services through the Service Registry, it will also have the ServiceReference in hand ...
But still, there may be report tooling not able to cope with ServiceReferences ?
Regards
Felix
Re: [HC] Use service registration properties
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 14, 2013 at 11:33 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I mean not having these at all :) and just have them as service
> properties. Filtering services based on the tags can be done using the
> filter expression based on service properties and registering the checks as
> mbeans works this way as well...
Ok, that's how it's done now.
> Do we have other use cases ?
We need some of these values (HC name and tags at least) in the
webconsole and MBeans when we output a Result. We usually don't have a
ServiceReference there, just HealthCheck, so it's much more convenient
to be able to access that info from a HealthCheck.
-Bertrand
Re: [HC] Use service registration properties
Posted by Carsten Ziegeler <cz...@apache.org>.
No, I mean not having these at all :) and just have them as service
properties. Filtering services based on the tags can be done using the
filter expression based on service properties and registering the checks as
mbeans works this way as well.
Do we have other use cases ?
Carsten
2013/8/14 Bertrand Delacretaz <bd...@apache.org>
> Hi Carsten,
>
> On Tue, Aug 13, 2013 at 8:27 PM, Carsten Ziegeler <cz...@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
cziegeler@apache.org
Re: [HC] Use service registration properties
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <fm...@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 <cz...@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
cziegeler@apache.org
Re: [HC] Use service registration properties
Posted by Felix Meschberger <fm...@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 <cz...@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
Re: [HC] Use service registration properties
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carsten,
On Tue, Aug 13, 2013 at 8:27 PM, Carsten Ziegeler <cz...@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