| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Fix #23609
Commit 629efb6 introduced thread safety to logger silencing but it
didn't take into account the fact that the logger can be extended with
broadcasting to other logger.
This commit introduces local_level to broadcasting Module which enables
broadcasted loggers to be properly silenced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `rails console` or `rails server` are used along with a logger set to output to `STDOUT` then the contents will show up twice. This happens because the logger is extended with `ActiveSupportLogger.broadcast` with a destination of STDOUT even if it is already outputting to `STDOUT`.
Previously PR #22592 attempted to fix this issue, but it ended up causing NoMethodErrors. A better approach than relying on adding a method and flow control is to inspect the log destination directly. For this `ActiveSupport::Logger.logger_outputs_to?` was introduced
```ruby
logger = Logger.new(STDOUT)
ActiveSupport::Logger.logger_outputs_to?(logger, STDOUT)
# => true
```
To accomplish this we must look inside of an instance variable of standard lib's Logger `@logdev`. There is a related Ruby proposal to expose this method in a standard way: https://bugs.ruby-lang.org/issues/11955
|
| |
|
|
|
|
|
| |
- uses instance defined level if no custom local log level defined
- Keeps track of local log level per [ thread + object-instance ]
- prevents memory leakage by removing local level hash key/value on #silence method exit
- avoids the use of Thread local variables
|
| |
|
|
| |
Logger#silence extension
|
| | |
|
| |
|
