| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
backport runner fixes to 3-2-stable
Conflicts:
railties/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| | |
Add a runner hook to Rails::Application and Rails::Engine that requires
ActiveRecord::Base to avoid circular constant loading when using observers.
This commit backports cc7dd66, c0ba0f0 and 8d01c61.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moral of the story: One must be careful about lazily initializing
instance variables when subclassing.
I would like to draw your attention to https://github.com/rails/rails/issues/4652 where
the reader will see that there appears to be some kind of initialization issue
in rails.
The source of this issue is that:
1) Engine#env_config contains "@env_config ||= ..."
2) Application#env_config contains "@env_config ||= ..."
3) Threads are in the picture
4) Thread A calls Application#env_config, which super's to Engine#env_config
5) After Engine#env_config returns but before Application#env_config sets @env_config again, Thread B begins running
6) Thread B calls Application#env_config
7) Thread B finds @env_config to contain a value (the one set by Engine#env_config) and returns it
8) Thread B blows up because key set by Application#env_config are there.
9) People report bugs with puma, thin, rainbows, webrick, etc
10) Evan becomes tired of seeing these bugs
11) Evan pours himself a stiff drink, puts on Top Gear(tm), and begins debugging
12) Evan finds the source of the bug
13) Evan authors a PR
14) RIGHT NOW.
The bug is fixed by simply using a different ivar name in the methods.
Alternately, Engine#env_config could just return a new Hash each time, not memoizing into @env_config.
I bid you adieu.
|
|
|
|
|
| |
This will make possible to do a frameworkless initialization since the
the default middleware stack is self contained.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This behaves similarly to REQUEST_URI, but
we need to implement it on our own because
REQUEST_URI is not reliable.
Note that since PATH_INFO does not contain
information about trailing question mark,
this is not 100% accurate, for example
`/foo?` will result in `/foo` in ORIGINAL_FULLPATH
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
replaced).
|
|
|
|
| |
instance, hooking on fsevents).
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c2e3ce8d1e1174e66536d59d8d97eb2cc8ce6f25.
Conflicts:
railties/lib/rails/application/configuration.rb
railties/lib/rails/application/finisher.rb
railties/lib/rails/engine.rb
|
|
|
|
|
|
|
|
| |
This can be turned off by setting `config.reload_classes_only_on_change` to false.
Extensions like Active Record should add their respective files like db/schema.rb and db/structure.sql to `config.watchable_files` if they want their changes to affect classes reloading.
Thanks to https://github.com/paneq/active_reload and Pastorino for the inspiration. <3
|
| |
|
| |
|
|
|
|
| |
app_reloader_hooks.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
methods directly.
|
| |
|
|
|
|
| |
Rails::Application
|
|
|
|
| |
can include these methods
|
| |
|
|
|
|
| |
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
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from 3-1-stable to master
[3.1.0.rc1] Plugins inside engines not eager-loaded properly and their
rake tasks ignored
Working with the new support for plugins inside engines in Rails 3.1,
I found that certain things that work for regular plugins don't work
for these new nested plugins. In particular, these methods in
Rails::Engine don't seem to understand that an engine could have
nested plugins:
#load_tasks
#load_generators
#load_console
#eager_load!
A solution which worked out for me is to move the calls to
railties.all { ... } from the overriding methods in Rails::Application
into Rails::Engine.
|
|\
| |
| | |
Fix engine's generator
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
generator blocks
|
| |
|
|
|
|
| |
Fixes incompatibility introduced by Rake 0.9.0
|
| |
|
| |
|
| |
|
| |
|