| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Following the Rails guide which state that a logger needs to include
the `ActiveSupport::LoggerSilence` as well as
`ActiveSupport::LoggerThreadSafe` modules isn't enough and won't
work.
Here is a test cases with 3 tests that all fails
https://gist.github.com/Edouard-chin/4a72930c2b1eafbbd72a80c66f102010
The problems are the following:
1) The logger needs to call `after_initialize` in order to setup
some instance variables.
2) The silence doesn't actually work because the bare ruby Logger
`add` method checks for the instance variable `@logger`. We need to
override the `add` (like we used to in the ActiveSupport::Logger
class).
3) Calling `debug?` `info?` etc... doesn't work as the bare ruby
methods will check for the instance variable. Again we need to
override this methods (like we used to in the ActiveSupport::Logger
class)
The LoggerSilence won't work without LoggerThreadSafe, but the later
is not public API, the user shouldn't have to include it so I
modified to include it automatically.
Same for the `after_initialize` method. I find unuintitive to have
to call it directly. I modified to instance the variables when the
module get included.
|
| |
|
|
| |
This basically reverts 8da30ad6be34339124ba4cb4e36aea260dda12bc
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
This reverts related commits due to #22917.
|
| | |
|
| |\
| |
| | |
Document `Logger#broadcast_messages` option
|
| | | |
|
| |/
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
| |
When setting the Rails logger to log to STDOUT, it would broadcast the
log twice in development. This adds a setting that will prevent messages
from being broadcast to multiple logs, while still allowing calls to
`#close`, `#level=`, `#progname=`, and `#formatter=` to be broadcasted.
Fixes #14769, #11415
|
| | |
|
| |
|
|
|
|
| |
from core_ext/logger" (some confusion over deprecation)
This reverts commit d00f568a83a5159ed93618b1081bd17858536d1c.
|
| |
|
|
| |
core_ext/logger
|
| |
|
|
| |
Logger#silence extension
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
from Ruby stdlib.
|
