| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/
|
|
|
|
|
|
|
| |
Railties.
The comment on the +env_config+ method is repetitive, likely to get
outdated, and provides no useful information which cannot be gleamed
from the code. I'm therefore removing it. I'm also refactoring the check
for the presence of a secret_token in the configuration.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A regression was introduced in 5b3bb6, generating route from within an
engine to an another engine resulted in prefixing a path with the
SCRIPT_NAME value.
The regression was caused by the fact that SCRIPT_NAME should be
appended only if it's the SCRIPT_NAME for the application, not if it's
SCRIPT_NAME from the current engine.
closes #10409
|
| | |
|
| | |
|
| |
|
|
| |
Automatically configure cookie-based sessions to use the best cookie jar given the app's config
|
| |
|
|
| |
signed cookies generated by Rails 3 to avoid invalidating them when upgrading to Rails 4
|
| |
|
|
| |
Check 862389c9537dbb6f65fd26c4325e07607ed437b5 for more background.
|
| |
|
|
| |
Check pull request #9789 for more information.
|
| | |
|
| |
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
railites_order method, introduced in 40b19e0, had a bug that was causing
loading application instance twice in initializers if railties_order
already included application instance. So for example
railties_order = [Foo::Engine, :main_app, Bar::Engine]
would result in such railties array:
[MyApp::Application, Foo::Engine, MyAppApplication, Bar::Engine]
In order to fix it, we need to check for existence of application in
both railties_order and railties arrays.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Also make sure to not use default queue consumer with custom queue
implementation. It is up to the new queue implementation to
start / shutdown the consumer.
|
| |
|
|
| |
Remove deprecation warning of method redefined.
|
| |
|
|
| |
queues
|
