Guides.rubyonrails.org

Chapters

This guide first describes the process of rails server then explains the Passenger + Rack method, before delving into the common initialize pattern these two go through.

The Boot Process

rails server

As of Rails 3, script/server has become rails server. This was done to centralise all rails related commands to one common file.

The actual rails command is kept in railties/bin/rails and goes like this:

As we can see here it will check for a script/rails file and if it exists it will exec it. We’ll get to that in a moment. If the file doesn’t exist it will generate the application using the rails/commands/application generator. The exec method is Kernel#exec and will run the file it’s given, and the second argument will be passed in as the arguments for that file. In script/rails we see the following:

This obviously defines a couple of constants to some pretty important files, config/environment.rb, config/boot.rb and config/application.rb all within the context of __FILE__ which is of course script/rails in the root of your application. Then it goes on to require BOOT_PATH which leads us onto config/boot.rb.

Passenger

Before we dive into what config/boot.rb encompasses, we’ll just glimpse at what Passenger does enough to get an understanding of how it requires a Rails application.

Passenger will require config/environment.rb by way of its PhusionPassenger::Railz::ApplicationSpawner#preload_application method. config/environment.rb requires config/application.rb which requires config/boot.rb. That’s how the Rails boot process begins with Passenger in a nutshell.

config/boot.rb

config/boot.rb is the first stop for everything for initializing your application. This boot process does quite a bit of work for you and so this section attempts to go in-depth enough to explain what each of the pieces does.

Bundled Rails (3.x)

Rails 3 now uses Bundler and the README for the project explains it better than I could:

> “Bundler is a tool that manages gem dependencies for your ruby application. It takes a gem manifest file and is able to fetch, download, and install the gems and all child dependencies specified in this manifest. It can manage any update to the gem manifest file and update the bundle’s gems accordingly. It also lets you run any ruby code in context of the bundle’s gem environment.”

Now with Rails 3 we have a Gemfile which defines the basics our application needs to get going:

Here the only two gems we need are rails and sqlite3-ruby, so it seems. This is until you run bundle pack. This command freezes all the gems required by your application into vendor/cache. The gems installed by default are:

• abstract (1.0.0)
• actionmailer (3.0.0.beta)
• actionpack (3.0.0.beta)
• activemodel (3.0.0.beta)
• activerecord (3.0.0.beta)
• activeresource (3.0.0.beta)
• activesupport (3.0.0.beta)
• arel (0.2.0)
• builder (2.1.2)
• bundler (0.9.1)
• erubis (2.6.5)
• i18n (0.3.3)
• mail (2.1.2)
• memcache-client
• mime-types
• rack (1.1.0)
• rack-mount (0.4.5)
• rack-test (0.5.3)
• rails (3.0.0.beta)
• railties (3.0.0.beta)
• rake (0.8.7)
• sqlite3-ruby
• text-format (1.0.0)
• text-hyphen (1.0.0)
• thor (0.13.0)
• tzinfo (0.3.16)

I won’t go into what each of these gems are, as that is really something that needs covering on a case-by-case basis. We will however just dig a little under the surface of Bundler.

Back in config/boot.rb, the first line will try to include .bundle/environment.rb, which doesn’t exist in a bare-bones Rails application and because this file does not exist Ruby will raise a LoadError which will be rescued and run the following code:

Bundler.setup here will load and parse the Gemfile and add the lib directory of the gems mentioned and their dependencies (and their dependencies’ dependencies, and so on) to the $LOAD_PATH.

Now we will go down the alternate timeline where we generate a .bundle/environment.rb file using the bundle lock command. This command also creates a Gemfile.lock file which is actually a YAML file loaded by this method in Bundler before it moves on to check for Gemfile:

The .bundle/environment.rb file adds the lib directory of all the gems specified in Gemfile.lock to $LOAD_PATH.

Frozen Rails (2.x)

If you’d still like to use the old school method of using a frozen Rails you may, by putting it into vendor/rails and uncommenting these lines in config/boot.rb:

Requiring Rails

The final non-commented line in config/boot.rb, require rails/all, does exactly that: requires all of Rails. If you’d like a certain gem to not be required, you may comment out or remove this line and uncomment the last 6 lines and pick-and-choose which you want to be included. If for example you didn’t want to include ActiveResource the final lines of your config/boot.rb would look like this:

require "rails/all"

Now we’ll dive into the internals of the pre-initialization stage of Rails. The file that is being required is railties/lib/rails/all.rb. The first line in this file is:

require 'rails'

This file (railties/lib/rails.rb) requires the very, very basics that Rails needs to get going. I’m not going to delve into these areas yet, just cover them briefly for now. Later on we will go through the ones that are important to the boot procedure.

require 'pathname' requires the Pathname class which is used for returning a Pathname object for Rails.root so that instead of doing:

You may do:

Although this is not new to Rails 3 (it was available in 2.3.5), it is something worthwhile pointing out.

This is the file that defines the helper methods such as Rails.root, Rails.env, Rails.logger and Rails.application.

The first facet of Rails to be included here is active_support.

require 'active_support'

activesupport/lib/active_support.rb sets up module ActiveSupport:

This defines two methods on the module itself by using the familiar class << self syntax. This allows you to call them as if they were class methods: ActiveSupport.on_load_all and ActiveSupport.load_all! respectively. The first method simply adds loading hooks to save them up for loading later on when load_all! is called. By call’ing the block, the classes will be loaded. (NOTE: kind of guessing, I feel 55% about this).

The on_load_all method is called later with the Dependencies, Deprecation, Gzip, MessageVerifier, Multibyte and SecureRandom. What each of these modules do will be covered later.

This file goes on to define some classes that will be automatically loaded using Ruby’s autoload method, but not before including Rails’s own variant of the autoload method from active_support/dependencies/autoload.rb:

Then it uses the method eager_autoload also defined in active_support/dependencies/autoload.rb:

As you can see for the duration of the eager_autoload block the class variable @@eager_autoload is set to true, which has the consequence of when autoload is called that the location of the file for that specific autoload‘d constant is added to the @@autoloads hash initialized at the beginning of this module declaration. So now that you have part of the context, here’s the other, the code:

So we know the ones in eager_autoload are eagerly loaded and it does this by storing them in an @@autoloads hash object. This is then referenced by the ActiveSupport::Autoload.eager_autoload! method which will go through and require all the files specified. This method is called in an initializer and will be covered much later in this guide.

The ones that are not eager_autoload’d are automatically loaded as they are called.

Note: What it means to be autoloaded. An example of this would be calling the ActiveSupport::TestCase class which hasn’t yet been initialized. Because it’s been specified as an autoload Ruby will require the file that it’s told to. The file it requires is not defined in the autoload call here but, as you may have seen, in the ActiveSupport::Autoload.autoload definition. So once that file has been required Ruby will try again and then if it still can’t find it it will throw the all-too-familiar uninitialized constant error.

require 'active_support/core_ext/kernel/reporting'

This file extends the Kernel module, providing the methods silence_warnings, enable_warnings, with_warnings, silence_stderr, silence_stream and suppress. The API documentation on these overridden methods is fairly good and if you wish to know more have a read.

require 'active_support/core_ext/logger'

The first line in this file is require 'active_support/core_ext/class/attribute_accessors' which defines methods such as cattr_accessor, cattr_reader and cattr_writer which are used later when the Logger class is extended.

This is another class that is well documented except for a set of the methods it defines which are the around helpers specified for all levels of logging: debug, info, error and fatal. The benefit of these methods is that if you want to output your debugging information wrapped in say, 50 stars top and bottom, you can do this in your (TODO: pick a file, any file.)

Your info output will now have 50 stars above it, and 50 below it. This is handy for locating the relevant information in a massive output.

Alternatively you could just silence one of the other streams by using silence:

Now you won’t get any SQL output in your logs.

require 'rails/application'

Here’s where Rails::Application is defined. This is the superclass of YourApp::Application from config/application.rb and the subclass of Rails::Engine This is the main entry-point into the Rails initialization process as when your application is initialized, your class is the basis of its configuration.

This file requires three important files before Rails::Application is defined: rails/railties_path.rb, rails/plugin.rb and rails/engine.rb.

require 'rails/railties_path'

This file serves one purpose:

Helpful, hey? One must wonder why they just didn’t define it outright.

require 'rails/plugin'

Firstly this file requires rails/engine.rb, which defines our Rails::Engine class, explained in the very next section.

This file defines a class called Rails::Plugin which descends from Rails::Engine.

TODO: Expand.

require 'rails/engine'

This file requires rails/railtie.rb which defines Rails::Railtie.

Rails::Engine defines a couple of initializers for your application:

• set_load_path
• set_autoload_paths
• add_routing_paths
• add_routing_namespaces
• add_locales
• add_view_paths
• add_metals
• add_generator_templates
• load_application_initializers
• load_application_classes

How these are loaded and run is covered later on.

Also in here we see that a couple of methods are delegate’d:

This means when you call either the middleware, paths or root methods you are in reality calling config.middleware, config.paths and config.root respectively.

Rails::Engine descends from Rails::Railtie.

require 'rails/railtie'

Rails::Railtie provides a method of classes to hook into Rails, providing them with methods to add generators, rake tasks and subscribers. Some of the more noticeable railties are ActionMailer, ActiveRecord and ActiveResource and as you’ve probably already figured out, the engines that you use are railties too. Plugins also can be railties, but they do not have to be.

Here there’s requires to rails/initializable.rb and and rails/configurable.rb.

require 'rails/initializable'

The Rails::Initializable module includes methods helpful for the initialization process in rails, such as the method to define initializers: initializer. This is included into Rails::Railtie so it’s available in Rails::Engine, Rails::Application and YourApp::Application. In here we also see the class definition for Rails::Initializer, the class for all initializer objects.

require 'rails/configuration'

The Rails::Configuration module sets up shared configuration for applications, engines and plugins alike.

At the top of this file rails/paths.rb and rails/rack.rb are require’d.

TODO: Expand on this section.

require 'rails/paths'

TODO: Figure out the usefulness of this code. Potentially used for specifying paths to applications/engines/plugins?

require 'rails/rack'

This file sets up some autoload’d modules for Rails::Rack.

require 'rails/version'

Now we’re back to rails.rb. The line after require 'rails/application' in rails.rb is:

The code in this file declares Rails::VERSION so that the version number can easily be accessed. It stores it in constants, with the final version number being attainable by calling Rails::VERSION::STRING.

require 'rails/deprecation'

This sets up a couple of familiar constants: RAILS_ENV, RAILS_ROOT and RAILS_DEFAULT_LOGGER to still be usable, but raise a deprecation warning when they are. Their alternatives (explained previously) are now Rails.env, Rails.root and Rails.logger respectively.

require 'rails/subscriber'

TODO: Explain Rails 3 subscribers. They appear to be a system outside the scope of Rails that is notified when certain events happen. The documentation explains it, but really need to see it in a larger context to make sense of what this does.

require 'rails/ruby_version_check'

This file ensures that you’re running a minimum of 1.8.7. If you’re running an older version, it will tell you:

  Rails requires Ruby version 1.8.7 or later.
  You're running [your Ruby version here]; please upgrade to continue.

require 'activesupport/railtie'

This file declares two railties, one for ActiveSupport and the other for I18n. Furthermore, it also sets up some initializers that these railties run when they are loaded.

require 'action_dispatch/railtie'

As this file is required last its initializer will be ran last. This calls require 'rails/dispatcher' which loads the ActionController::Dispatch class.

TODO: Figure out why it is loading something that is deprecated and what it should be loading instead.

Return to rails/all.rb

Now that we’ve covered the extensive process of what the first line does in this file, lets cover the remainder:

ActiveRecord Railtie

The ActiveRecord Railtie takes care of hooking ActiveRecord into Rails. This depends on ActiveSupport ActiveModel, ARel.

require "active_record"

TODO: Why are activesupport_path and activemodel_path defined here?

The first three requires require ActiveSupport, ActiveModel and ARel in that order:

require "active_support"

This was loaded earlier by railties/lib/rails.rb. This line is here as a safeguard for when ActiveRecord is loaded outside the scope of Rails.

require "active_model"

TODO: Again with the activesupport_path!

Here we see another require "active_support" this is again, a safeguard for when ActiveModel is loaded outside the scope of Rails.

This file defines a few autoload’d modules for ActiveModel, requires active_support/i18n and adds the default translation file for ActiveModel to I18n.load_path.

The require 'active_support/i18n' just loads I18n and adds ActiveSupport’s default translations file to I18n.load_path too:

require "arel"

This file in arel/lib/arel.rb loads a couple of ActiveSupport things first:

Inflections, Transliteration & Friends

This file is activesupport/lib/active_support/inflector.rb and makes a couple of requires out different files tasked with putting inflections in place:

This file is activesupport/lib/active_support/inflector/inflections.rb and defines the ActiveSupport::Inflector::Inflections class which defines the singularize, pluralize, humanize, tableize, titleize and classify methods as well as the code to defining how to work out the irregular, singular, plural and human versions of words. These methods are called irregular, singular, plural and human respectively, as is the Rails way.

This file is activesupport/lib/active_support/inflector/transliterate.rb and defines two methods, transliterate and parameterize. What transliterate does depends on your Ruby version. If you have something greater than 1.9 installed it will just print out a warning message using the Kernel#warn method (simply called using warn) reading “Ruby 1.9 doesn’t support Unicode normalization yet”. If you’re running something that’s not 1.9 it will attempt to convert "föö" to foo and if that fails then it’ll redefine it.

This file first makes a require to activesupport/lib/active_support/core_ext/string/multibyte.rb which then goes on to require activesupport/lib/active_support/multibyte.rb and that requires activesupport/core_ext/module/attribute_accessors.rb. The attribute_accessors.rb file is used to gain access to the mattr_accessor (module attribute accessor) method which is called in active_suport/multibyte.rb. Also in active_support/multibyte.rb there’s a couple of autoloaded classes:

There’s also these method definitions:

These methods are used in activesupport/lib/active_support/core_ext/string/multibyte.rb.

If we go back to activesupport/lib/active_support/core_ext/string/multibyte.rb_, this file makes a couple of extensions to the String class based on if your version of Ruby’s String class responds to the forceencoding method. This method was introduced in Ruby 1.9. If you’re using 1.9 the methods are defined like this:

You can see that calling mb_chars on a String instance in Ruby 1.9 will simply return that String object. String objects in Ruby 1.9 are already multibyte strings, so Rails does not need to do any conversion on them.

The second method, is_utf8? return true if the String object is of the UTF8 encoding or if it’s able to be forced into that encoding and false if it can’t force its encoding or if the encoding of the string is neither UTF8, ASCII_8BIT or US_ASCII.

If you’re using a Ruby version less than 1.9 there are 3 methods defined instead of 2, and they are defined like this:

As you can see, mb_chars is where the proxy_class method comes in handy. This will create a new instance of that class and pass in the String object in order to make it multibyte-compatible. In this case the new String object will be an instance of the ActiveSupport::Multibyte::Chars class. You can use ActiveSupport::Multibyte.proxy_class= to set this to be a different class if you’re that way inclined.

Here, is_utf8? calls a consumes method on the not-yet-loaded ActiveSupport::Multibyte::Chars class. The keen-eye would have seen this was specified as an auto-load earlier, so that is what is going to happen if we call this method or mb_chars. This means that it’ll require the file located at activesupport/lib/active_support/multibyte/chars.rb. This file includes activesupport/lib/active_support/string/access.rb which defines methods such as at, from, to, first and last. These methods will return parts of the string depending on what is passed to them and they are defined differently depending on if you’re using Ruby 1.9 or not. The second file included is activesupport/lib/active_support/string/behaviour.rb which defines a single method acts_like_string? on String which always returns true. This method is used through the acts_like? method which is passed a single argument representing the downcased and symbolised version of the class you want to know if it acts like. In this case the code would be acts_like?(:string).

The Chars class defines, along with consumes?, other methods such as the “spaceship” method <=>. This method is referenced by the methods defined in the included Comparable module and will return

Firing it up!

Now that we’ve covered the boot process of Rails the next line best to cover would be what happens after script/rails has loaded config/boot.rb. That’s quite simply that it then require 'rails/commands' which is located at railties/lib/rails/commands.rb. Remember how exec passed the arguments to script/rails? This is where they’re used. rails/commands.rb is quite a large file in Rails 3, as it contains all the Rails commands like console, about, generate and, of course, server. Because we’ve called rails server the first argument in ARGV is of course "server". So assuming this we can determine that the ARGV.shift in commands.rb is going to return "server", therefore it’ll match this when:

The keen-eyed observer will note that this when also specifies the argument could also be simply 's' thereby making the full command rails s. This is the same with the other commands with generate becoming g, console becoming c and dbconsole becoming db.

This code here ensures we are at the ROOT_PATH of our application (this constant was defined in script/rails) and then calls Rails::Server.start. Rails::Server descends from Rack::Server which is defined in the rack gem. The Rails::Server.start method is defined like this:

We can see here that there is usual output indicating that the server is booting up.

How the options variable gets set and how Rack starts the server up is covered in the next section.

Racking it up!

This Rack::Server.start method is defined like this:

new as you know calls initialize in a class, and that is defined like this:

And then options, which are the options referenced by the start method in Rails::Server.

And parse_options:

And default_options:

Finally! We’ve arrived at default_options which leads into our next point quite nicely. After the object has been initialize’d, start is called:

We’re not debugging anything, so there goes the first 7 lines, we’re not warning, nor are we including, requiring, daemonising or writing out a pid file. That’s everything except the final line, which calls run with the wrapped_app which is then defined like this:

and build_app’s first and only argument is app which is defined like this:

options is a method we talked about a short while ago, which is just the set of default options. options[:config] in this context is therefore config.ru which coincidentally we have in our application! To get an application instance from this method Rack::Builder joins the fray with a call to parse_file on our config.ru:

First this reads your config file and checks it for #\ at the beginning. This is supported if you want to pass options into the Rack::Server instance that you have and can be used like this:

TODO: Is the above correct? I am simply guessing!

After that it removes all the content after any __END__ in your config.ru (TODO: because? Is this so it doesn’t get eval’d?) and then evals the content of this file which, as you’ve seen is quite simple. The code that’s first evaluated would be the require to the config/environment.rb file, which leads into the next section.

config/environment.rb

Now that we’ve seen that rails/server gets to config/environment.rb via Rack’s requiring of it and Passenger requires it straight off the line. We’ve covered the boot process of Rails and covered the beginnings of a Rack server starting up. We have reached a common path for both rails/server and Passenger now, so let’s investigate what config/environment.rb does.

As you can see, there’s a require in here for config/application.rb, and this file looks like this:

These options (and their siblings) are explained in a later section. What’s important to note for this file currently is that this is where the YourApp::Application class is initialized and that it’s a subclass of Rails::Application. This is the first point where your application begins to initialize Rails and as you can see all of this is configuration stuff which your initializers and really, the rest of your application will depend on. These options and what they do will be covered later.

Rails Initialization Process

Now begins the actual initialization of Rails. Previously we have covered how rails server and Passenger get to this stage and the parts of Rails that they have both loaded.

Rails::Application

The first steps for the initialization process of Rails begins when YourApp::Application descends from Rails::Application. The Rails::Application class descends from Rails::Engine class which itself descends from Rails::Railtie defined in railties/lib/rails/railtie.rb. Along this fantastical chain of superclasses, there’s defined a couple of inherited class methods. These methods just so happen to be called when a class inherits from (aka: is made a subclass of) this class. This first one is for Rails::Application:

This goes up the chain by using super to calling Rails::Engine.inherited:

called_from references where this code was called from. This is covered later on in the “Bootstrap Initializers” section.

Which then calls Rails::Railtie.inherited:

This inherited first includes the Rails::Configurable module on base, which is YourApp::Application. This module defines the config method on YourApp::Application, and now it’s starting to come together. You may notice that in your config/application.rb file there’s a config method called there. This is the method from Rails::Configurable.

Then this adds to Rails::Railtie.subclasses your application’s class because… TODO: explain.

With Rails::Railtie.inherited out of the way, and that being the last thing to do in Rails::Engine.inherited we return to Rails::Application.inherited which calls the following:

As you already know, base is YourApp::Application and now it’s calling the instance method on it. This method is defined in Rails::Application like this:

The new method here simply creates a new Rails::Application and sets it to the @@instance class variable. No magic.

Your Application’s Configuration

Now that inherited has finished doing its job, next up in config/application.rb is the call to the config object’s methods. As explained before, this config object is an instance of Rails::Railtie::Configuration, put into place by the call of include Rails::Configurable back in Rails::Railtie.inherited. This defined it as such:

All the methods for Rails::Railtie::Configuration are defined like this in railties/lib/rails/railtie/configuration.rb:

As you can probably guess here, the Rails::Configuration module is defined by rails/configuration (railties/lib/rails/configuration.rb).

Rails::Configuration::Shared

In a standard application, the application.rb looks like this with all the comments stripped out:

The config method being the one defined on Rails::Application::Configurable:

The method find_with_root_flag is defined on Rails::Engine (the superclass of Rails::Application) and it will find the directory containing a certain flag. In this case it’s the config.ru file:

called_from goes through the caller which is the stacktrace of the current thread, in the case of your application it would go a little like this:

  /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails/application.rb:30:in `inherited'
  /home/you/yourapp/config/application.rb:4:in `<module:TestApp>'
  /home/you/yourapp/config/application.rb:3:in `<top (required)>'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `block in require'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:537:in `new_constants_in'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require'
  /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails/commands.rb:33:in `<top (required)>'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `block in require'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:537:in `new_constants_in'
  /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0.beta1/lib/active_support/dependencies.rb:167:in `require'
  /var/www/rboard/script/rails:10:in `<main>'

called_from is defined in the inherited method for Rails::Engine which looks like this:

The call_stack here is the caller output shown previously, minus everything after the first : on all the lines. The first path that matches this is /usr/local/lib/ruby/gems/1.9.1/gems/railties-3.0.0.beta1/lib/rails. Yours may vary slightly, but should always end in railties-x.×.x/lib/rails.

The code in find_root_with_flag will go up this directory structure until it reaches the top, which in this case is /.

TODO: What is all this for?

At the root of the system it looks for config.ru. TODO: Why? Obviously it’s not going to find it, so it uses the default option we’ve specified which is Dir.pwd which will default to the root folder of your Rails application. This path is then passed to Rails::Application::Configuration.new. Rails::Application::Configuration descends from Rails::Engine::Configuration and the initialize method goes like this:

The super method here is the initialize method in Rails::Engine::Configuration:

Here, the @root variable is assigned the path of your application and then the remainder of Rails::Application::Configuration.initialize is ran, setting up a few instance variables for basic configuration, including one for @filter_parameters.

Now with the config option set up, we can go onwards and call filter_parameters on it. This filter_parameters method is not defined on Rails::Configuration::Shared and actually falls to the method_missing defined there instead:

We’re not calling filter_parameters=, we’re calling filter_parameters, therefore it’ll be the second part of this ternary argument: options[$1]. The options method is defined like this:

OrderedOptions exists… TODO: explain.

So from this we can determine that our options hash now has a key for filter_parameters which’s value is an array consisting of a single symbol: :password. How this option manages to get into the @filter_parameters variable defined on the Rails::Application::Configuration.initialize method is explained later.

Application Configured!

Now your application has finished being configured (at least in the sense of config/application.rb, there’s more to come!) in config/environment.rb the final line calls YourApp::Application.initalize!.

Initialization begins

This is one of those magical uses of method_missing which, for the purposes of debugging, is something that you don’t expect to come across as often as you do and as a consequence you’ll spend a good portion of an hour looking for method definitions that don’t exist because method_missing is taking care of it. There’s some pretty crafty use of method_missing all over Rails and it’s encouraged to take note of its power.

Rails::Application has a method_missing definition which does this:

With our instance being our already initialized by the inherited method, this will just return the value of the @@instance variable, a Rails::Application object. Calling initialize! on this method does this:

The initializers it is talking about running here are the initializers for our application. The object passed in to run_initializers is YourApp::Application.

run_initializers

This method begins the running of all the defined initializers. In the section “The Boot Process” we covered the loading sequence of Rails before any initialization happens and during this time we saw that the Rails::Railtie class includes the Initializable module. As we’ve also seen YourApp::Application is a descendant of this class, so it too has these methods.

run_initializers looks like this:

Here the initializers method is defined in railties/lib/rails/application.rb:

Bootstrap initializers

The first line here references a Bootstrap class we haven’t seen before. Or have we? The keen-eyed observer would have spotted an autoload for it at the top of Rails::Application:

Now that we’ve referenced that class, it will be required for us. You’ll notice inside this class that there’s an include Initializable, providing the afore-mentioned methods from this module. Inside this class a number of initializers are defined.

• load_environment_config
• load_all_active_support
• preload_frameworks
• initialize_logger
• initialize_cache
• initialize_subscriber
• set_clear_dependencies_hook
• initialize_dependency_mechanism
• bootstrap_load_path

These are all defined using the initializer method:

The initializers method defined here just references an @initializers variable:

As you can see from this method it will set opts[:after] if there are previously defined initializers. So we can determine from this that the order our initializers are defined in is the same order that they run in, but only by default. It is possible to change this by specifying an :after or :before option as we will see later on. Each initializer is its own instance of the Initializer class:

Now that Rails::Application::Bootstrap has finished loading, we can continue on with our initialization. We saw that it called this:

Calling initializers_for, defined like this:

The binding argument here is YourApp::Application and this will return a new Initializer object for all the initializers in initializers_chain for this particular context. initializers_chain goes like this:

The ancestors list is relatively short for Rails::Application::Bootstrap, consisting of itself and Rails::Initializable. Rails will go through these ancestors in reverse and check them all if they respond_to?(:initializers). Rails::Initializable does not and so it’s skipped. Rails::Application::Bootstrap of course does, and this is the list of initializers we covered earlier.

After initializers_chain is finished, then they are map’d like this, with the binding of course being YourApp::Application as explained previously.

Wow. All that to cover just the first line in the initializers method for Rails::Application.

Railties Initializers

This section covers the loading of the initializers and we will go into depth for each initializer in the next section, as they make more sense explained in their chain.

The second line in Rails::Application#initializers:

calls railties, which is defined like this:

This sets up a new Rails::Application::Railties object like this:

And calls all on it:

This all method executes code on all the Rails::Railtie and Rails::Engine subclasses, retreived by the railties and engines methods defined right after all:

By default, the railties are:

• ActiveSupport::Railtie
• I18n::Railtie
• ActionDispatch::Railtie
• ActionController::Railtie
• ActiveRecord::Railtie
• ActionView::Railtie
• ActionMailer::Railtie
• ActiveResource::Railtie
• Rails::TestUnitRailtie

And these all descend from Rails::Railtie.

The default engines are [].

The plugins method it calls is a little more complex:

@config.paths is defined in the Rails::Application::Configuration like this:

When we call @config.paths.vendor.plugins it will return "vendor/plugins".

If you’ve defined specific plugin requirements for your application in config/application.rb by using this code:

or specific plugin loading using a similar statement such as this next one:

Then this is where the @config.plugins comes from. If you wish to load only certain plugins for your application, use the first example. If you wish to load certain plugins before the rest then the second example is what you would use.

If config.plugins is not defined then :all is specified in its place. Whatever the plugin_names is specified as, is passed to Plugin.all along with the path to the plugins, @config.path.vendor.plugins (which defaults to vendor/plugins):

As we can see here it will go through the paths and for every folder in vendor/plugins and initialize a new Rails::Plugin object for each:

This sets the plugin name to be the same name as the folder so the plugin located at vendor/plugins/by\_star_’s name is bystar. After that, the config object is initialized:

and the root of the plugin defined as that folder. The reasoning for defining a root is so that the initializer called load_init_rb has some place to look for this file:

A little more on that later, however.

If the plugin is not included in the list then it moves on to the next one. For all plugins included in the list (or if :all is specified in the list) they are put into a plugins local variable which is then sorted:

The sort order is the same order as which they appear in the config.plugins setting, or in alphabetical order if there is no setting specified.

Now that we have our railties, engines, and plugins in a line we can finally get back to the all code:

This block will gather add the railties’ initializers to it.

Engine Initializers

The third line in this initializers method:

The super method it’s referring to is of course Rails::Engine.initializers, which isn’t defined on the class but, as we have seen before, is defined on the Rails::Railtie class it inherits from through the Rails::Initializable module. Therefore we can determine the initializers to be added are now the ones defined in Rails::Engine.

Finisher Initializers

The final set of initializers in this chain are those in Rails::Finisher. This involves running any after initialize code, building the middleware stack and adding the route for rails/info/properties.

Running the Initializers

Now that we have all the initializers we can go back to the run_initializers in Rails::Initializable:

Now we finally have all the initializers we can go through them and call run:

You may remember that the @context in this code is YourApp::Application and calling instance_exec on this class will make a new instance of it and execute the code within the &block passed to it. This code within the block is the code from all the initializers.

Bootstrap Initializers

These initializers are the very first initializers that will be used to get your application going.

load_environment_config

This quite simply makes a call to require_environment! which is defined like this in Rails::Application:

We’ve seen config.paths before when loading the plugins and they’re explained in more detail in the Bonus section at the end of this guide. config.enviroment for paths is defined like this:

Rails.env was defined way back in the boot process when railties/lib/rails.rb was required:

With ENV["RAILS_ENV"] and ENV["RACK_ENV"] not set to anything for our server booting process, this will default to "development".

Therefore the path to this config file line would look like this with a substitution made:

This method returns a Path object (which acts as an Enumerable).

Back to require_environment now:

And we’ve determined that config.paths.config.environment is Path object, and calling to_a on that object calls paths because it’s alias’d at the bottom of the Path class definition:

This returns an array of files according to our path and @glob which are config/environments and development.rb respectively, therefore we can determine that:

will return an Array containing one element, "config/enviroments/development.rb". Of course when we call first on this Array we’ll get the first element and because that exists, we now require "config/environments/development.rb".

This file contains the following by default:

This configure method is an alias of class_eval on Rails::Application:

therefore, the code inside of the configure is evaluated within the context of YourApp::Application.

The config object here is the same one that was set up when config/application.rb was loaded, therefore the methods called in this object will fall to the method_missing defined in Rails::Configuration::Shared:

This time we are using methods ending in \=, so it will set the key in the options to be the value specified. The first couple of options, cache_classes, whiny_nils, consider_all_requests_local are just simple keys on the options. If you recall how options were setup then you may be able to work out how the remaining action_view, action_controller and action_mailer methods work.

Firstly, we’ll cover how config_key_regexp is defined:

And also config_keys:

config_keys in here returns:

With all of those keys coming from Railtie::railtie_names. If you’ve elected to not load some of the frameworks here they won’t be available as configuration keys, so you’ll need to remove them too.

Now a reminder of how the options key is defined:

The values for these framework keys are ActiveSupport::OrderedOptions objects, with the class defined like this:

We can determine when we call config.action_view.debug_rjs it’s falling back to the method_missing defined on ActiveSupport::OrderedOptions, which ends up either setting or retrieving a key. In this case because we’re using a setter, it will set the key for this hash. This completes the loading of config/environments/development.rb.

load_all_active_support

This initializer does exactly what it says:

If you don’t want this to happen you can specify the config.active_support.bare option to true in either config/application.rb or any of your environment files.

preload_frameworks

Remember earlier how we had all that stuff eager_autoload’d for ActiveSupport?

This is where it gets loaded. The eager_autoload! method is defined like this:

With @@autoloads being

• load_all_active_support
• preload_frameworks
• initialize_logger
• initialize_cache
• initialize_subscriber
• set_clear_dependencies_hook
• initialize_dependency_mechanism
• bootstrap_load_path

ActiveSupport Initializers

ActiveSupport

ActiveSupport Initializers

• active_support.initialize_whiny_nils
• active_support.initialize_time_zone

I18n Initializers

• i18n.initialize

The I18n::Railtie also defines an after_initialize which we will return to later when discussing the initializers in detail.

ActionDispatch Initializers

• action_dispatch.prepare_dispatcher

ActionController Initializers

• action_controller.logger
• action_controller.set_configs
• action_controller.initialize_framework_caches
• action_controller.set_helpers_path

ActiveRecord Initializers

• active_record.initialize_time_zone
• active_record.logger
• active_record.set_configs
• active_record.log_runtime
• active_record.initialize_database_middleware
• active_record.load_observers
• active_record.set_dispatch_hooks

ActionView Initializers *

• action_view.cache_asset_timestamps

ActionMailer Initializers *

• action_mailer.logger
• action_mailer.set_configs
• action_mailer.url_for

ActiveResource Initializers

• active_resource.set_configs

Rails::Engine Initializers

• set_load_path
• set_autoload_paths
• add_routing_paths ******************************************** ******************************************** ******************************************** ********************************************

EVERYTHING AFTER THIS POINT HAS NOT BEEN UPDATED TO REFLECT THE RAILS 3 BETA RELEASE. HERE BE DRAGONS. DANGER, WILL ROBINSON, DANGER. CONTINUE AT YOUR OWN PERIL!!!

---

---

---

---

Rails::Engine.new

The new method doesn’t exist, but in Ruby classes calling new on the class instantiates a new instance of that class and calls the instance method initialize on it. This method for Rails::Application goes like this:

Rails::Application#require_environment

This is not a crafty method like the previous ones, it just does as it says on the box:

The config object here is actually another delegate’d method (along with routes), this time to self.class:

So the method call is actually self.class.config.

Rails::Application.config

Defined back inside the class << self for Rails::Application, config makes a new Rails::Application::Configuration object and caches it in a variable called @config:

Rails::Plugin::Configuration.default

The Rails::Plugin::Configuration class may be a bit difficult to find at first, but if you look for plugin.rb in Rails, you’ll find it in railties/lib/rails/plugin.rb. In this file, we see the following:

So we note here that Rails::Plugin descends from Rails::Railtie and secondly we note that the class Configuration is not actually included in the Plugin class, but it is in the Railtie class!

Rails::Railtie::Configuration

We’ve now tracked down the Plugin::Configuration.default method to being Railtie::Configuration.default, which is defined like this in railties/lib/rails/configuration.rb:

In this case we have effectively seen that it’s doing Configuration.new(Configuration.new). I’ll explain why.

Rails::Application::Configuration.new

TODO: CLEAN THIS UP! This subclassing is only temporary and will probably not be separate in Rails 3. This is based solely off what the comment at the top of the Railtie::Configuration class says!

The first thing to note here is that this class is subclassed from Railtie::Configuration and therefore the method here is actually Railtie::Configuration.new. As mentioned previously, calling new will make a new object of this class and then call initialize on it, which is defined like this:

This method is not called with a base argument for Plugin::Configuration.default but it is for the Configuration.new wrapped around it. We’ll go for the internal one first, since that’s the order Rails loads them in.

default_middleware_stack

This method is defined like this:

To really understand this method we need to dig a little deeper, down into where ActionDispatch::MiddlewareStack.new is defined and what in particular it does for us.

ActionDispatch::MiddlewareStack.new

ActionDispatch is our first foray outside of the railties gem, as this is actually defined in the actionpack part of Rails. The class definition is as important as the method:

When it’s calling super here it’s actually calling initialize on the Array class and from this we can determine that an ActionDispatch::MiddlewareStack object is just an Array object with special powers. One of those special powers is the ability to take a block, and call it with self, meaning the block’s parameter is the object itself!

ActionDispatch::MiddlewareStack.use

Previously we saw a chunk of code that I’ll re-show you stripped down:

As explained in the previous section, we know that the new on ActionDispatch::MiddlewareStack takes a block and that block has one parameter which is the object itself. On this object we call the use method to include middleware into our application. The use method simply does this:

We’ll come back to this method later on.

ActionController::Middleware.new

This initialize method also is in a class who’s ancestry is important so once again I’ll show the ancestry and we’ll go up that particular chain:

Here our method calls super but with a difference: it’s passing in no arguments intentionally by putting the two brackets at the end. The method called here is therefore ActionController::Metal.initialize.

ActionController::Metal.initialize

This is another subclassed class, this time from ActionController::AbstractController and I’m sure you can guess what that means:

The single * in the argument listing means we can accept any number of arguments, we just don’t care what they are.

AbstractController::Base.initialize

This may be anti-climatic, but the initialize method here just returns an AbstractController::Base object:

ActionDispatch::MiddlewareStack.use

Now we’re back to this method, from our foray into the depths of how Middleware.new works, we’ve showed that it is an instance of AbstractController::Base. Therefore it does

TODO: ELABORATE ON THIS SECTION, including explaining what all the pieces of middleware do. Then explain how the default_middleware_stack does what it does, whatever that is.

Back to Rails::Application::Configuration.new

Now that the first call to this method is complete (Plugin::Configuration.default), we can move onto the second call. Here’s a refresher of what this method does:

You’ll note now that this method is being called now is Configuration.new(Plugin::Configuration.default) and with the argument, it’s going to perform differently than before, this time duplicating the options and middleware of the object it was passed.

TODO: Find out what purpose the @options and @middleware variables serve.

Finally, a Rails::Application::Configuration object will be returned. On this class there are a couple of attr_accessors and attr_writers defined:

Along with these are a lot of helper methods, and one of them is environment_path:

Back to Rails::Application#require_environment

Now that we have a Rails::Application::Configuration object for the config method, we call the environment_path which, as we’ve seen above, just requires the current environment file which in this case is config/environments/development.rb. If this file cannot be found, the LoadError require throws will be rescue’d and Rails will continue on its merry way.

config/environments/development.rb

In a standard Rails application we have this in our config/environments/development.rb file:

It’s a little bit sneaky here, but configure is alias‘d to class_eval on subclasses of Rails::Application which of course includes YourApp::Application. This means that the code inside the configure do block will be evaled within the context of YourApp::Application. The config method here is the one mentioned before: the Rails::Application::Configuration object. The methods on it should look familiar too: they’re the ones that had attr_accessor and attr_writer definitions.

The ones down the bottom, config.action_controller, config.action_view and config.action_mailer aren’t defined by attr_accessor or attr_writer, rather they’re undefined methods and therefore will trigger the method_missing on the Rails::Application::Configuration option.

config.cache_classes=

The first method call in this file, this tells Rails to not cache the classes for every request. This means for every single request Rails will reload the classes of your application. If you have a lot of classes, this will slow down the request cycle of your application. This is set to false in the development environment, and true in the test & production environments.

config.whiny_nils=

If this is set to true, like it is here in the development environment, activesupport/whiny_nil will be require’d. Have you ever seen this error:

Or perhaps this one?

If you have, then this is activesupport/whiny_nil at work.

The frameworks

As mentioned before, the methods action_controller, action_view and action_mailer aren’t defined on the Rails::Application::Configuration object, rather they are caught by method_missing which does this:

Whilst this code is not obvious at first, a little bit of further explanation will help you understand. config_key_regexp is another method (a private one, like method_missing) defined here:

As is config_keys:

Aha! There we’ve got mention of action_view, but what is in Railtie.plugin_names? Most likely in this case the other frameworks.

Railtie.plugin_names

I’m going to show you two methods since the third one, self.plugin_name, calls the second one, self.plugins and they’re right after each other:

In here we see that we get the plugin_names from a variable called @plugins… which we haven’t seen yet. Through the power of the wonderful inherited the @plugins variable is populated. inherited is called when a class inherits, or subclasses, from this class. Therefore we can determine that the other classes are probably inheriting or subclassing from Rails::Railtie.

Serving a Request

Now that your application is fully initialized, it’s now ready to start serving requests.

rails server

For servers running through rails server you may recall that this uses Rails::Server which is a subclass of Rack::Server. Previously we covered the initialization process of Rack but not completely up to the point where the server was running. Now that’s what we’ll do. Back when the Rack::Server class was first covered there was a mention of the start method which we only touched on. It goes a little like this:

We were at the point of explaining what wrapped_app was before we dived into the Rails initialization process.Now that we have a wrapped_app we pass it as the first argument to server.run. server in this instance is defined like this:

Our options Hash is still the default, and there is no server key set in default_options, so it will default to Rack::Handler.default. This code works like this:

We don’t have PHP_FCGI_CHILDREN in our ENV, so it’s not going to be FastCGI. We also don’t have REQUEST_METHOD in there, so it’s not going to be CGI. If we have Mongrel installed it’ll default to that and then finally it’ll use WEBrick. For this, we’ll assume a bare-bones installation and assume WEBrick. So from this we can determine our default handler is Rack::Handler::WEBrick.

(side-note: Mongrel doesn’t install on 1.9. TODO: How do we format these anyway?)

Rack::Handler::WEBrick

This class is subclassed from WEBrick::HTTPServlet::AbstractServlet which is a class that comes with the Ruby standard library. This is the magical class that serves the requests and deals with the comings (requests) and goings (responses) for your server.

Rack::Server has handlers for the request and by default the handler for a rails server server is

Passenger

Cruft!

The final line of config/environment.rb:

gets down to actually initializing the application!

TODO: Cover the other config.* methods in perhaps a “Bonus” section near the end. If they aren’t referenced in a config file they aren’t that important, right?

TODO: This belongs in the guide, I just don’t know where yet. Maybe towards the end, since this is really the “final” thing to be done before being able to serve requests.

Because we don’t have any middleware for our application, this returns the application itself( Guessing here!! TODO: Investigate if this is really the case.)

Now that we have an app instance, the last line in start calls server.run wrapped_app, options. We know what our app is, and that our options are just the default options, so what is server? server is this:

Since we have default options, the server is obviously going to be Rack::Handler.default. The default method goes like this:

Rails::Paths

The super method it references comes from Rails::Engine::Configuration which defines these paths: