Because of the possibility of lib being unintentionally eager loaded it's been agreed that we'll leave autoload paths and eager load paths separate for Rails 4.0. This reverts commit 0757b33. Conflicts: railties/CHANGELOG.md
Since the default in Rails 4.0 is to run in 'threadsafe' mode we need to eager load all of the paths in `autoload_paths` so we alias `eager_load_paths` to it. This may have unintended consequences if you have added 'lib' to `autoload_paths` such as loading unneeded code or code intended only for development and/or test environments. If this applies to your application you should thoroughly check what is being eager loaded.
These warnings were actually a bug in Ruby 2.0, the accessors should not be raising such warnings, they are only meant for ivars. - Revert "fix warnings in Ruby 2.0" This reverts commit 26702a6. - Revert "Merge pull request #8282 from arunagw/warning_removed_for_ruby2" This reverts commit f63d654, reversing changes made to 3a89068.
…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.
When you mount your application at a path, for example /myapp, server should set SCRIPT_NAME to /myapp. With such information, rails application knows that it's mounted at /myapp path and it should generate routes relative to that path. Before this patch, rails handled SCRIPT_NAME correctly only for regular apps, but it failed to do it for mounted engines. The solution was to hardcode default_url_options[:script_name], which is not the best answer - it will work only when application is mounted at a fixed path. This patch fixes the situation by respecting original value of SCRIPT_NAME when generating application's routes from engine and the other way round - when you generate engine's routes from application. This is done by using one of 2 pieces of information in env - current SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because we have 2 cases to handle: - generating engine's route from application: in this situation SCRIPT_NAME is basically SCRIPT_NAME set by the server and it indicates the place where application is mounted, so we can just pass it as :original_script_name in url_options. :original_script_name is used because if we use :script_name, router will ignore generating prefix for engine - generating application's route from engine: in this situation we already lost information about the SCRIPT_NAME that server used. For example if application is mounted at /myapp and engine is mounted at /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that we need to keep reference to /myapp SCRIPT_NAME by binding it to the current router. Later on we can extract it and use when generating url Please note that starting from now you *should not* use default_url_options[:script_name] explicitly if your server already passes correct SCRIPT_NAME to rack env. (closes #6933)
This reverts commit 6acebb3. Usage of this feature did not reveal any improvement in existing apps. Conflicts: actionpack/lib/action_dispatch/routing/mapper.rb guides/source/routing.textile railties/lib/rails/engine.rb railties/lib/rails/paths.rb railties/test/paths_test.rb
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.
- Many engines rely on being able to join directories to the Rails root: Rails.root.join('somedir') - This was now impossible because Rails.root returned a String: NoMethodError: undefined method `join' for "/code/myrailsapp":String - This was broken in 4001835
This feature enables the ability to load an external routes file from the router via: draw :filename External routes files go in +config/routes+. This feature works in both engines and applications.