Multi check page support

[alexsaar]

currently you can have multiple pages but each of them shows the same status and providers. It might be useful to have the option to create multiple pages with different providers/status infos.

This would allow better access control for different users or tools requesting the status. Also it would allow to group status based on their calculation impact, eg one page that only has core status info which can be polled often and which is easy to calculate. And then another page with more heavy calculations that can be checked after an installations, update or restore etc.

[alexsaar]

just discussed with Jörg: we could tag health status provider and allow selecting tags in page props of check page. this would prevent use of components

[mhaack]

+1

Am 07. November 2012 um 13:46 schrieb Alexander Saar notifications@github.com:

just discussed with Jörg: we could tag health status provider and allow selecting tags in page props of check page. this would prevent use of components

— Reply to this email directly or view it on GitHub.

[alexsaar]

@joerghoh can you have a look at this? I implemented multi page support. this includes:

• ability to tag status providers
• select tags for a status page via page props
• allow to overwrite bundle threshold for a specific page via page props

[alexsaar]

Hi Jörg,

I don't really see the benefit of adding CQ Tags in the Basic tab of a statuspage, when you can specify a free-from category in the categories tab. I would create only 1 tab with all relevant pieces there. And relevant might be: Title, category, bundleThreshold, maybe HideInNav.

My initial idea was to use CQ Tags. But maintaining them in an OSGI config for the providers is not very nice so I switched to plain text free form tags. However I though keeping the CQ Tags to provide another way of categorization might be handy (they are also used for search in many places in CQ). But I'm OK with removing that.

When we can specify the bundleThreshold per category in the statuspage, we tie a HealthStatusService to a statuspage for configuration. Can't we create a HealthStatusServices via a FactoryConfiguration and define the categories pluis threshold on an specific instance of it? Then you can choose on a statuspage, which category should be displayed. Looks all more elegant for me.

Not sure if I understand this fully. Are you suggesting to shift the config for displayed categories from the page to another service factory and then define for each page which instance of HealthStatusService is should use? If so then I think this is another indirection that is not really required and makes it harder to setup new check pages.

We can have multiple StatusServices each querying a different set of StatusProviders; is it possible to add a kind of master StatusService, which queries all other StatusServices? How can we map that into a master statuspage, so could have the "child" statuspages appearing there as clickable links?

Right now if you don't specify a category you get all status info (which would be the same as a master status page). So I don't think there is a need for another aggregation layer.

[alexsaar]

finally merged this change into the master after fixing some things that were not working properly.

@joerghoh I wanted to get this in to proceed with some other restructuring work that we had planned for the next version. it basically works now and is very flexible. but feel free to change or extend it with your recommendations wrt Factory service etc. I'm still not entirely sure why multiple instances of the HealthStatusService would be better. But Maybe I just need to see it in code )