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.
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.
* 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.
