Feature #11955

Expose Object that Receives logs in Logger

Added by schneems (Richard Schneeman) about 1 year ago. Updated 9 months ago.

Target version:


I need to be able to perform logic based on the destination of a current logger, this is currently not possible without instance_variable_get. Why would you need to see what destination a logger is going to? There is a common pattern in long lived programs like webservers. You want logs on disk for later reference, but you also want them in STDOUT to make development and debugging easier. Rails does this in development mode. Since there is no way to see if a logger is already going to STDOUT, it gets extended to log to STDOUT so logs show up twice.

While that example was complicated the logic I want is very simple: if you have a logger that is logging to STDOUT, do nothing, otherwise log to STDOUT and current logger. You cannot do this today without exposing the destination of the logger. This patch exposes the logger destination and allows us to write code like this:

def make_sure_logging_to_stdout(logger)
  unless logger.destination == STDOUT   # <==== Cannot do this today
    stdout_logger =
    logger.extend(Module do
      def add((*args, &block)
        stdout_logger.add(*args, &block)
        super(*args, &block)

logger =

logger.fatal("An error has occured")

We should be able to inspect the destination of a logger, this patch enables this functionality.

ruby-changes.patch View (1.04 KB) schneems (Richard Schneeman), 01/05/2016 09:58 PM

ruby-changes.patch View (2.17 KB) schneems (Richard Schneeman), 01/19/2016 08:02 PM


#1 [ruby-core:72734] Updated by schneems (Richard Schneeman) about 1 year ago

Here is a patch to Rails that could benefit from standardizing access to the logger destination object:

#2 [ruby-core:72750] Updated by nobu (Nobuyoshi Nakada) about 1 year ago

  • Description updated (diff)

Your example doesn't seem to able to get rid of adding stdout_logger twice or more, even with logger.destination.

Maybe won't it be better to do in LogDevice layer?

#3 [ruby-core:72776] Updated by schneems (Richard Schneeman) about 1 year ago

Your example doesn't seem to able to get rid of adding stdout_logger twice or more, even with logger.destination.

It took a long time to write that example to be short, maybe I missed some details. A real world example is in that linked pull request, you can see the comparison I implemented this is where I would like to use a public interface instead of instance_variable_get.

LogDevice already exposes the destination, but Logger does not expose the LogDevice object. I did not know if there was a reason people did not what to provide access to LogDevice. Would you prefer that I submitted a patch to expose the LogDevice instead?

#4 [ruby-core:72938] Updated by schneems (Richard Schneeman) about 1 year ago

Nobu, I've added a new patch that would expose the LogDevice object in a Logger instance. This would be acceptable for my needs.

#5 [ruby-core:72949] Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • Status changed from Open to Assigned
  • Assignee set to sonots (Naotoshi Seo)

#6 [ruby-core:74344] Updated by schneems (Richard Schneeman) about 1 year ago

Anything else that needs to be done for this patch?

#7 [ruby-core:75010] Updated by sonots (Naotoshi Seo) 11 months ago

I am wondering of the interface yet.

Users pass an io object to Logger constructor as logdev like, so getting the io object from Logger#logdev seems natural. However,

attr_reader :logdev

returns a LogDevice instance rather than io object, which seems natural from the view of source codes.

#8 [ruby-core:76083] Updated by schneems (Richard Schneeman) 9 months ago

Sorry for the delay, does not send me emails for some reason.

The first patch I attached returned which is the IO object. It was discussed that to do this Logger must know too much about the logdev interface and it would be simpler to expose the logdev instead.

Either approach will work for my use cases. Now that 2.4.0 preview is out is there a feature freeze? Is there any chance this will come out in time for christmas?

Also available in: Atom PDF