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.
…tion [Closes #2507] Changes: * `Rails.initialized=` has been removed * `Rails.initialized?` and `Rails.application.initialized?` are now * delegating to `MyApp::Application.initialized?`
…5225) This makes rails behave properly when you serve static assets and you have X-Sendfile headers enabled. Nevertheless in most cases you should not rely on that and serve static assets with a webserver like Apache or Nginx (as you already have it in place anyway if you use X-Sendfile)
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
…(for instance, hooking on fsevents).
This reverts commit c2e3ce8. Conflicts: railties/lib/rails/application/configuration.rb railties/lib/rails/application/finisher.rb railties/lib/rails/engine.rb
…changed. 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