Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NDavid Heinemeier Hansson <david@loudthinking.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

removes Array#random_element and backports Array#sample from Ruby 1.9, thanks to Marc-Andre Lafortune

Still copy application configuration to generator even if they are required earlier. Also tidy up the guide a little bit.

Add lib to load paths when application is inherited to be able to load lib code during configuration.

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

Still copy application configuration to generator even if they are required earlier. Also tidy up the guide a little bit.

Add lib to load paths when application is inherited to be able to load lib code during configuration.

If you have existing Metals, you have a few options:
* if your metal behaves like a middleware, add it to the
  middleware stack via config.middleware.use. You can use
  methods on the middleware stack to control exactly where
  it should go
* if it behaves like a Rack endpoint, you can link to it
  in the router. This will result in more optimal routing
  time, and allows you to remove code in your endpoint
  that matches specific URLs in favor of the more powerful
  handling in the router itself.

For the future, you can use ActionController::Metal to get
a very fast controller with the ability to opt-in to specific
controller features without paying the penalty of the full
controller stack.

Since Rails 3 is closer to Rack, the Metal abstraction is
no longer needed.

Fix a bug where I18n fallbacks modules where not included in the proper backend if it was set through config.i18n.backend.

[#4652 state:resolved]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NXavier Noria <fxn@hashref.com>

This reverts commit ade756fe.

This reverts commits af0d1a88 and 64d109e3.

* Default Encoding.default_internal to UTF-8
* Eliminated the use of file-wide magic comments to coerce code evaluated inside the file
* Read templates as BINARY, use default_external or template-wide magic comments
  inside the Template to set the initial encoding
  * This means that template handlers in Ruby 1.9 will receive Strings encoded
    in default_internal (UTF-8 by default)
* Create a better Exception for encoding issues, and use it when the template
  source has bytes that are not compatible with the specified encoding
* Allow template handlers to opt-into handling BINARY. If they do so, they
  need to do some of their own manual encoding work
* Added a "Configuration Gotchas" section to the intro Rails Guide instructing
  users to use UTF-8 for everything
* Use config.encoding= in Ruby 1.8, and raise if a value that is an invalid
  $KCODE value is used

Also:
* Fixed a few tests that were assert() rather than assert_equal() and
  were caught by Minitest requiring a String for the message
* Fixed a test where an assert_select was misformed, also caught by
  Minitest being more restrictive
* Fixed a test where a Rack response was returning a String rather
  than an Enumerable

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Ensure that eager_load actually takes place just after the middleware stack is built by using another pattern.

Also create a engine_blank_point initializer to ensure any :before or :after hooks defined inside engines won't move the configuration initializers to other places.