Add support for configuring logger groups via loggers endpoint

[htztomic]

This is a fix to GitHub issue #16680 . The LoggerGroupsEndpoint gives support for GET configurations of logger groups or a single logger group as well configuring the LogLevel of a specific logger group.

[snicoll]

Thanks for the PR. I had a quick look at this enhancement a while back and was wondering if we couldn't use the existing loggers endpoint for that. As you went the route of a dedicated endpoint, I'd love to hear your thoughts.

I've also added a few questions/suggestions.

[snicoll]

Without looking at the concrete details, I would have updated the existing LoggersEndpoint to handle both logger names and groups. While we're at the mercy of having a group having the same name as a logger, I wonder if handling them in a single place wouldn't be easier.

[snicoll]

I am not entirely sure I get the rationale of this. IMO, If we go down the route of having a dedicated endpoint, I don't think it should 404 depending of the fact that at least a group is defined or not.

[snicoll]

Have you considered updating LoggingSystem rather than registering another singleton in the context? Given that became a feature handled there, perhaps we should expose it rather than having to lookup another type.

[snicoll]

@htztomic I missed the conversation of using a separate endpoint while I was on PTO, sorry about that. Please ignore that part of the review for now.

[wilkinsona]

When we added support for logging groups we did so without making any, I think, changes to the logging systems. I wonder if we should strive to do the same here? Would it work if we pulled out a separate class, say LoggerGroups, that was responsible for managing the groups and passing the level changes for each logger in a group down to the LoggingSystem? A LoggerGroups instance could be made available as a bean in a similar manner to how the LoggingSystem is made available.

[snicoll]

Gah, that's exactly what @htztomic had and I suggested in my review to avoid registering yet another bean.

[wilkinsona]

IMO, registering another bean is preferable to adding another responsibility to LoggingSystem implementations. A middle-ground would be to introduce LoggerGroups as @htztomic originally proposed, but provide access to it via a getLoggerGroups() on LoggingSystem rather than registering it as a bean. I still prefer the bean registration approach, however. There's no technical need for LoggingSystem to know about logger groups and I'd prefer to keep that separation.