Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add first class support for disabling logback ConsoleAppender #1612

Closed
btiernay opened this issue Sep 24, 2014 · 7 comments
Closed

Add first class support for disabling logback ConsoleAppender #1612

btiernay opened this issue Sep 24, 2014 · 7 comments
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@btiernay
Copy link

It would be nice not to have to redefine the logback.xml just to disable CONSOLE. Could we do this with a standard property like logging.console? Please see http://stackoverflow.com/questions/26019350/how-to-disable-logback-consoleappender-in-spring-boot/26019508?noredirect=1#comment40754570_26019508 for more details

@btiernay
Copy link
Author

See the following for one such approach that doesnt require adding janino as a dependecy due to conditional configuration: http://stackoverflow.com/questions/23651466/overriding-logback-configurations

@dsyer
Copy link
Member

dsyer commented Sep 25, 2014

I'd actually like to have the opposite (be able to disable the FILE appender). I also think that we should disable the FILE appender by default in 1.2 (implying that it can be switched on externally), so let's try and do all of those things in one ticket?

@dsyer dsyer added the type: enhancement A general enhancement label Sep 25, 2014
@dsyer dsyer added this to the 1.2.0.M2 milestone Sep 25, 2014
@btiernay
Copy link
Author

Sounds great, thanks!

@dsyer dsyer added the status: ideal-for-contribution An issue that a contributor can help us with label Sep 29, 2014
@btiernay
Copy link
Author

Curious as to your thoughts on how DW handles logging:

Basically they make it possible to configure everything in their settings.yml. This has the side effect of imposing Logback on the user.

@dsyer
Copy link
Member

dsyer commented Sep 30, 2014

We allow log levels to be configured in application.yml (.properties), but that works for all log providers. I think that and the location of log files are by far the most common things to change (if you don't like the Boot defaults for format you might add a logback.xml once and never have to change it), so that seems like a good balance to me. So I like it the way it is.

@philwebb philwebb modified the milestones: 1.2.0.RC1, 1.2.0.M2 Oct 10, 2014
liujiong1982 added a commit to liujiong1982/spring-boot that referenced this issue Oct 16, 2014
1 disable the file output unless LOG_FILE is set
2 make the console optional

fixes: spring-projectsgh-1612
liujiong1982 added a commit to liujiong1982/spring-boot that referenced this issue Oct 28, 2014
1 disable the file output unless LOG_FILE is set
2 make the console optional

fixes: spring-projectsgh-1612
dsyer pushed a commit that referenced this issue Oct 28, 2014
1 disable the file output unless LOG_FILE is set
2 make the console optional

fixes: gh-1612
@dsyer dsyer closed this as completed in aec3856 Oct 28, 2014
@philwebb philwebb reopened this Oct 30, 2014
@philwebb philwebb self-assigned this Oct 30, 2014
@philwebb philwebb removed the status: ideal-for-contribution An issue that a contributor can help us with label Oct 30, 2014
philwebb added a commit that referenced this issue Oct 30, 2014
Prior to this commit LoggingSystem initialization would happen multiple
times. Once to configure "quiet" logging, and again to configure correct
settings once the Application was initialized. This could cause problems
if `logging.groovy` logback files were used.

The logging system is now only initialized once (when possible) by
following these steps:

- Standard logging initialization occurs via the actual logging
  implementation used (e.g. logback will load a logback.xml file if it
  exists)
- beforeInitization() is called to prevent early log output.
  Implementations now either use a Filter or simply set the root logging
  level.
- initialize() is called with an optional log configuration file (e.g
  a custom logback.xml location) and an optional log output file (the
  default is null indicating console only output).

The initialize() method will attempt to prevent double initialization
by checking if a standard configuration file exists. Double
initialization now only occurs in the following situations:

- The user has a standard configuration file (e.g. classpath:logback.xml)
  but also specifies a logging.config property. Double initialization is
  required since the specified configuration file supersedes the default.
- The user has a standard configuration file (e.g. classpath:logback.xml)
  and specifies a logging.file property. Double initialization is
  required since the standard configuration may use a ${LOG_FILE}
  reference.

In addition this commit removes the `logging.console` option and now
assumes that logging either occurs only to console or to both the
console and a file. This restriction helps simplify the LoggingSystem
implementations. If file only logging is required a custom logback.xml
can be used.

Fixes gh-1091
See gh-1612, gh-1770
@philwebb philwebb added the status: declined A suggestion or change that we don't feel we should currently apply label Oct 30, 2014
@philwebb
Copy link
Member

Unfortunately I think adding a logging.console option adds too much complexity to the code. If you want file only logging your best option is to create your own logback.xml configuration. Version 1.2 has some reworked base files so you should be able to use something like this and just drop the console-appender.xml import.

@ChinaXing
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
5 participants