Provide LoggingEndpoint

[vpavic]

This is driven by discussion in #4486.

I've started some work on a PR but would like to use this issue to discuss the operations this endpoint would provide as well as some implementation details.

This endpoint would be based on Boot's logging abstraction (LoggingSystem) and would provide the following operations:

• get a list all known loggers
• get a logger details by its name
• set level for a give logger

ATM LoggingSystem implementations internally keep their mappings between Boot's LogLevel and their native log levels. This is used when setting the log levels, which is already supported by logging abstraction. However, with this PR logging abstraction would also need to support get operations which in turn requires resolution of log levels in other direction (resolve LogLevel for given native log level).

I've originally considered making the level mappings bi-directional but this isn't possible since the mappings are not one-on-one in LogbackLoggingSystem and JavaLoggingSystem (see LogLevel.FATAL). Other idea would be to keep the cache of Boot's LogLevels for each registered logger. This cache would be initially populated during initialization of LoggingSystem.

@snicoll any thoughts on this?

[snicoll]

That is pretty much what I had in mind, a LoggingEndpoint that is exposed both via JMX and an MVC endpoint if that's available. The log level is a bit tricky indeed but a bi-directional mapping should be possible in some form.

I would also expose:

• The URL of the logging configuration (if any)
• If that's available, a refresh operation that would reload the configuration file. Not all logging system supports that so we can react with a proper exception/status code.

My only concern at this point is time as the roadmap for 1.4 is quite full already.

[vpavic]

The log level is a bit tricky indeed but a bi-directional mapping should be possible in some form.

@snicoll but how exactly would you resolve LogLevel from Logback's Level.ERROR having this in mind? Similar is with JUL.

My only concern at this point is time as the roadmap for 1.4 is quite full already.

If your are happy with 3 operations listed in my original message for the initial implementation, I've basically got everything implemented (including tests and configurations) with the exception of this mapping thing. We can expand it with other operations at some later stage.

[vpavic]

Here's what I've got so far:
https://github.com/vpavic/spring-boot/tree/logging-endpoint

@snicoll if you think this is the right direction I can create the PR off this branch.

[snicoll]

Actually there are similar features in Spring Cloud that we would like to reintegrate here for Spring Boot 2.0. Maybe you could give that a try and let us know what you think?

[vpavic]

Thanks for your feedback.

This was also mentioned in #4486, I've asked for a reference to this Spring Cloud feature but received no feedback.

Is this the feature you are referring to?

[snicoll]

partially, I thing @dsyer mentioned another feature but I can't remember right now.

[dsyer]

Yes, that's it (coupled with the fact that the /env endpoint accepts a POST).

[vpavic]

Are there any plans to support reading the current level of a logger and reloading the default configuration?

[dsyer]

No, but there would be no opposition to those features (here or in Spring Cloud). I guess those are arguments for having a dedicated endpoint.