| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Fix bug when log level of Rails.logger (which was set via config.logger) does not match the config.log_level.
|
|
|
|
|
|
| |
This reverts commit b7d9d6e2cd5082d269dafbc0316e2107febe1451.
Per discussion with @jeremy and @rubys on Campfire.
|
| |
|
| |
|
|
|
|
|
|
|
| |
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the eager load behavior was mostly coupled to
config.cache_classes, however this was suboptimal since in
some environments a developer may want to cache classes but
not necessarily load them all on boot (for example, test env).
This pull request also promotes the use of config.eager_load
set to true by default in production. In the majority of the
cases, this is the behavior you want since it will copy most
of your app into memory on boot (which was also the previous
behavior).
Finally, this fix a long standing Rails bug where it was
impossible to access a model in a rake task when Rails was
set as thread safe.
|
| |
|
| |
|
| |
|
|
|
|
| |
production so that PID and timestamp are logged. fixes #5388
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
from Ruby stdlib.
|
|
|
|
| |
app_reloader_hooks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
logs for a certain block, change the log level for that block.
* ActiveSupport::BufferedLogger#open_log is deprecated. This method should
not have been public in the first place.
* ActiveSupport::BufferedLogger's behavior of automatically creating the
directory for your log file is deprecated. Please make sure to create the
directory for your log file before instantiating.
* ActiveSupport::BufferedLogger#auto_flushing is deprecated. Either set the
sync level on the underlying file handle like this:
f = File.open('foo.log', 'w')
f.sync = true
ActiveSupport::BufferedLogger.new f
Or tune your filesystem. The FS cache is now what controls flushing.
* ActiveSupport::BufferedLogger#flush is deprecated. Set sync on your
filehandle, or tune your filesystem.
|
|
|
|
| |
production concerns
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To the app developer, this means configuration add in
config/initializers/* will not be executed.
Plugins developers need to special case their initializers that are
meant to be run in the assets group by adding :group => :assets.
Conflicts:
railties/CHANGELOG
railties/test/application/assets_test.rb
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this change, running code via script/runner would demonstrate
different logging behavior than running the same code via a rake task.
In production mode the script/runner approach would always flush the
logger, but the rake-based approach would not automatically flush the
logger. This discrepancy violates the principle of least surprise, and
it could lead to the loss of important production logging data.
This change removes special-case code in the "runner" command, and
replaces it with a general solution to ensure that the logger gets
flushed at exit. This solution works for "runner", "console", "server",
rake tasks, and any other process that loads the Rails environment.
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
method_missing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without the need for Railtie. Specifically, the following hooks were added:
* before_configuration: this hook is run immediately after the Application class
comes into existence, but before the user has added any configuration. This is
the appropriate place to set configuration for your plugin
* before_initialize: This is run after all of the user's configuration has completed,
but before any initializers have begun (in other words, it runs right after
config/environments/{development,production,test}.rb)
* after_initialize: This is run after all of the initializers have run. It is an
appropriate place for forking in a preforking setup
Each of these hooks may be used via ActiveSupport.on_load(name) { }. In all these cases, the context inside the block will be the Application object. This means that for simple cases, you can use these hooks without needing to create a Railtie.
|
|
|
|
| |
initializing the application on its own. This fixes [#4492 state:resolved] and also avoids the application being initialized twice in some rake tasks.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|