Feedback on changing log configuration

[benmccann]

Hi, 

I've submitted a PR to simplify logging by configuring log levels only in the logback.xml config. Since this would remove the ability to configure these levels in application.conf I wanted to run the idea by the mailing list.

Every project I've worked on, we've needed to end up creating a logback.xml eventually. The fact that we set logging up in the beginning in application.conf makes this harder because you have to create a new xml file and communicate to everyone on the team that we're now configuring logging in a different way. Inevitably some people end up forgetting and putting the logging configs in application.conf so that we have logging configured in two places which ends up being pretty confusing, especially if one of the configs overrides the other. If instead we created the logback.xml in the beginning, it becomes much easier for a new user to understand since there's only one way to do it and we provide a good starting point in the template that's easy to understand.

-Ben

[James Roper]

So, perhaps we should include a logback.xml in new project templates?  Would that help user experience?

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Ben McCann]

Yes, I do think we should do that. I've done that in my PR actually.

--

about.me/benmccann

[James Roper]

Right, I haven't got to going through my GitHub notifications for today :)

[Naftoli Gugenheim]

To turn the question around, what would it take to obviate the need for a logback.xml in the first place?

First of all, excuse my ignorance -- is play hardwired to use logback for its logging?

Anyway wouldn't it be ideal if the Play experience didn't include dealing with old-fashioned xml files?

So what would it take --- how complex is the xml configuration format, and what can it do that hocon can't do? And how hard is it to install a new configuration mechanism into logback?

I admit I haven't looked into any of the relevant code -- I'm writing this email offline so I can't now either. If someone that's familiar could fill me in on the technical details, I would really appreciate it.

[Jean Helou]

Logback preferred format is groovy actually. It supports XML as a second option but will resolve groovy config first.

In theory, most logging should go through the slf4j api with logback as the implementation.
Most likely logback is only explicitly referenced where the logging subsystem is started. With 2.4 it should be fairly easy to switch to another implem ...

I am not sure if it would be possible p do complex configuatio of the logging system through application.conf

[James Roper]

On 14 April 2015 at 16:14, Naftoli Gugenheim <nafto...@gmail.com> wrote:

To turn the question around, what would it take to obviate the need for a logback.xml in the first place?

First of all, excuse my ignorance -- is play hardwired to use logback for its logging?

Yes it is.  Play is a full stack framework, it provides everything out of the box.  Requiring the user to select a logging framework is not an option.  That doesn't mean we can't make it possible to plugin different logging frameworks, but by default, the user experience should be that they don't have to worry, they can let the framework select it for you.

Anyway wouldn't it be ideal if the Play experience didn't include dealing with old-fashioned xml files?

The fact that XML is old (and it's not that old, Javascript is older than XML) is not a valid reason not to use it.  Does it cause pain to use it in this instance?  I think the answer is no.  The only reason I can see to not use it is because it's not cool, and I would think the Play community is a little more mature than other communities that make decisions based on fads.

So what would it take --- how complex is the xml configuration format, and what can it do that hocon can't do? And how hard is it to install a new configuration mechanism into logback?

The problem with a new configuration mechanism is that it's unfamiliar, and something additional that we have to maintain and support.  If someone has having difficulty configuring logback, and they're not using a standard configuration mechanism, then the wealth of resources held by google won't be useful to them, the logback maintainers won't be interested in helping them on their mailing list because they're using something custom for Play, etc.

[Naftoli Gugenheim]

On Tue, Apr 14, 2015 at 2:29 AM James Roper <ja...@typesafe.com> wrote:

On 14 April 2015 at 16:14, Naftoli Gugenheim <nafto...@gmail.com> wrote:

To turn the question around, what would it take to obviate the need for a logback.xml in the first place?

First of all, excuse my ignorance -- is play hardwired to use logback for its logging?

Yes it is.  Play is a full stack framework, it provides everything out of the box.  Requiring the user to select a logging framework is not an option.  That doesn't mean we can't make it possible to plugin different logging frameworks, but by default, the user experience should be that they don't have to worry, they can let the framework select it for you.

I'm confused -- is anything hardwired to logback only, or is it just an out-of-the-box default choice than is possible to override?

What specifically uses logback by default? Logging that Play does? Play's logging helpers? (Sorry if this is getting out of scope for -dev.)

 

Anyway wouldn't it be ideal if the Play experience didn't include dealing with old-fashioned xml files?

The fact that XML is old (and it's not that old, Javascript is older than XML) is not a valid reason not to use it.  Does it cause pain to use it in this instance?  I think the answer is no.  The only reason I can see to not use it is because it's not cool, and I would think the Play community is a little more mature than other communities that make decisions based on fads.

Yeah I agree, I guess what bothers me most about xml is it's very verbose and thus tedious as well as hard to read.

 

So what would it take --- how complex is the xml configuration format, and what can it do that hocon can't do? And how hard is it to install a new configuration mechanism into logback?

The problem with a new configuration mechanism is that it's unfamiliar, and something additional that we have to maintain and support.  If someone has having difficulty configuring logback, and they're not using a standard configuration mechanism, then the wealth of resources held by google won't be useful to them, the logback maintainers won't be interested in helping them on their mailing list because they're using something custom for Play, etc.

I hear that. And it probably makes more sense to someone who, unlike me, has some familiarity with configuring logback. :) It sounds like it's not just a simple regular tree structure, but something more intricate.

[James Roper]

On 14 April 2015 at 17:42, Naftoli Gugenheim <nafto...@gmail.com> wrote:

On Tue, Apr 14, 2015 at 2:29 AM James Roper <ja...@typesafe.com> wrote:

On 14 April 2015 at 16:14, Naftoli Gugenheim <nafto...@gmail.com> wrote:

To turn the question around, what would it take to obviate the need for a logback.xml in the first place?

First of all, excuse my ignorance -- is play hardwired to use logback for its logging?

Yes it is.  Play is a full stack framework, it provides everything out of the box.  Requiring the user to select a logging framework is not an option.  That doesn't mean we can't make it possible to plugin different logging frameworks, but by default, the user experience should be that they don't have to worry, they can let the framework select it for you.

I'm confused -- is anything hardwired to logback only, or is it just an out-of-the-box default choice than is possible to override?

What specifically uses logback by default? Logging that Play does? Play's logging helpers? (Sorry if this is getting out of scope for -dev.)

Yes, there is a bit of setup that needs to be done to get a smooth logback experience.  We provide a default configuration file that gets used if the user hasn't otherwise provided one.  Currently, there is no way to disable that.