Since the Rack::Lock still exists in development, let's provide a way to disable it explicitly.
Removing it breaks functionality with gems such as Thinking Sphinx. This restores it with a deprecation warning. Closes #8551
…ping with Rails 4.0.
This allows easy upgrading from the old signed Cookie Store <= 3.2 or the deprecated one in 4.0 (the ones that doesn't use key derivation) to the new one that signs using key derivation
Setting the action_dispatch.rack_cache options to true or a hash should be the way to enable it.
…ain queues in the classes that use them instead.
Add ActiveSupport::KeyGenerator as a simple wrapper around PBKDF2
Available both as an env entry for rack and an instance method on Rails::Application for other uses
…mespaces 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.
The flag was mainly used to add a Rack::Lock middleware to the stack, but the only scenario the lock is desired is in development. If you are deploying on a not-threaded server, the Rack::Lock does not provide any benefit since you don't have concurrent accesses. On the other hand, if you are on a threaded server, you don't want the lock, since it defeats the purpose of using a threaded server. If there is someone out there, running on a thread server and does want a lock, it can be added to your environment as easy as: `use Rack::Lock`
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.
Closes #7110 there's more work to do on rack-cache issue 69
This allows us to do: In your configuration: Rails.queue[:image_queue] = SomeQueue.new Rails.queue[:mail_queue] = SomeQueue.new In your app code: Rails.queue[:mail_queue].push MailJob.new Both jobs pushed to the same default queue Rails.queue.push DefaultJob.new Rails.queue[:default].push DefaultJob.new
this is so we can show route output in the development when we get a routing error. Railties can use features of ActionDispatch, but ActionDispatch should not depend on Railties.
Since plugins were removed, we can clean up a few methods in engines. We also use this opportunity to move `load_console`, `load_tasks` and `load_runner` to Rails::Engine. This means that, if someone wants to improve script/rails for engines to support console or runner commands, part of the work is already done.