Merb Wiki

Editing Merb core boot process

Textile Enabled | [[Page Name]] for internal links
h2. What happens when you run merb executable. Once merb utility is run, it adds -a mongrel to ARGV unless other adapter specified and runs Merb.start. h3. Merb.start. Merb.start parses command line arguments using OptParse, sets resulting options to Merb::Config. Merb::Config is basically a Hash wrapper that provides some DSL facilities to set options, like the following Merb::Config.use do |conf| conf[:session_store] = 'memcache' end So if you are looking for command line options or options given to config in Ruby code (most likely in init file or plugin init file), it all comes to Merb::Config hash-like object. Onces initial configuration is set, Merb checks up action option. Note that at this point we only have configuration options from command line merged with default options hash. Init file is loaded later in the process. That's why if you set port option in config, pid file name does not respect it. But we are off the track. When action is either kill or kill_9, Merb::Server.kill is used to kill running Merb instances. Merb loads pid file, takes process id(s) from it and sends deadly signals using id(s). Of course you are much more interested in what happens when you start Merb application. If action is not kill or kill_9, Merb::Server.start is called. It is given two options: port and if you asked for a cluster of servers. Note that port and cluster option are taken from already discussed Merb::Config hash-alike object. h3. Merb::Server.start. The #start class method of Merb::Server does some dirty work with calculations of ports (if you asked for a cluster of servers), daemonization of processes and registring TERM and INT signal handlers. Then it just kicks off bootloader with BootLoader.run and when it is finished, starting Rack adapter (for Thin, Mongrel, etc). h3. Bootloaders. Ruby has a way of tracking classes subclassing this particular class. It is Class#inherited method that gets called on superclass when it is subclassed. Boot process in Merb is just a run of chain of runnable classes. When you subclass Merb::BootLoader the subclassing class name is put into Merb::BootLoader.subclasses collection. Merb::BootLoader.run just iterates through duplicate of that collection and calls run method on every subclass (Object.full_const_get is used to get class from fully-qualified name in a string). Every class that has a run method and subclasses Merb::BootLoader is a "bootloader". There are several bootloaders in Merb core: * Merb::BootLoader::Logger * Merb::BootLoader::DropPidFile * Merb::BootLoader::BuildFramework * Merb::BootLoader::Dependencies * Merb::BootLoader::BeforeAppLoads * Merb::BootLoader::LoadClasses * Merb::BootLoader::Templates * Merb::BootLoader::MimeTypes * Merb::BootLoader::AfterAppLoads * Merb::BootLoader::MixinSessionContainer * Merb::BootLoader::ChooseAdapter * Merb::BootLoader::RackUpApplication * Merb::BootLoader::ReloadClasses * Merb::BootLoader::ReloadTemplates Logger bootloader initializes logger for Merb. Loggers don't come from the outer space, right? They are instantiated at some point. Merb::Bootloader::Logger.run does just that. DropPidFile bootloader stores pid file(s) if Merb is asked to daemonize or run in a cluster. BuildFramework bootloader attempts to load the following locations Merb.root / "config" / "framework.rb" Merb.root / "framework.rb" to set up application load paths (app/models, config, lib, etc). If none of them found, default set of load paths is used. Here it is: Merb.push_path(:application, Merb.root_path("app/controllers/application.rb")) Merb.push_path(:config, Merb.root_path("config"), nil) Merb.push_path(:router, Merb.dir_for(:config), (Merb::Config[:router_file] || "router.rb")) Merb.push_path(:lib, Merb.root_path("lib"), nil) Merb.push_path(:log, Merb.log_path, nil) Merb.push_path(:public, Merb.root_path("public"), nil) Merb.push_path(:stylesheet, Merb.dir_for(:public) / "stylesheets", nil) Merb.push_path(:javascript, Merb.dir_for(:public) / "javascripts", nil) Merb.push_path(:image, Merb.dir_for(:public) / "images", nil) Dependencies bootloader loads application init file, environment-specific init files, loads every dependency specified at this point (usually in init files), tries to load JSON gem with C extension, falls back to pure Ruby, updates logger with information from init files. You may recall config/init.rb in "regular" application structure merb-gen creates. This is default path for init file. Environment-specific config by default is looked up at Merb.config / "environments" / [environment name]. You can override init file location using command line option -I or --init-file. In this case Merb will load what you specify. BeforeAppLoads bootloader just runs hooks you provided as blocks to Merb::BootLoader.before_app_loads method, one by one. LoadClasses loads all classes in model, controller and lib directories in application structure (you can obtain them using Merb.dir_for(:lib) and so forth). Then requirements are loaded. This is where Merb starts tracking file modification time to do autoreloading if environment is configured to do it. Templates bootloader inlines all templates found under template paths for speed. Inlining method takes a template at a particular path and inlines it into a module and adds it to the METHOD_LIST table to speed lookup later. MimeTypes bootloader registers default formats Merb core aware of, ties them to serialization method names (like to_json or to_yaml) and content type. Formats are added with Merb.add_mime_type. AfterAppLoads bootloader does exactly what BeforeAppLoads but for after_app_loads hooks. MixinSessionContainer bootloader checks what session store (memory, cookies, memcache) specified in Merb::Config and loads container class for it. Once it is loaded, it is included into Merb::Controller. Then container is checked for secret and session id keys. Note that if your session store is not registered at the point MixinSessionContainer bootloader runs, cookie store is used and warnings are logged. ORM plugins provide database session store and if plugin is not installed, this fallback will take place. ChooseAdapter bootloader sets Merb.adapter to Rack adapter class taken from Merb::Config (option name is :adapter and this is what you specify using -a option on command line). Nothing else. To obtain the class Merb::Rack::Adapter.get method is used. RackUpApplication bootloader loads so called rackup file that starts Rack. By default it is rack.rb under Merb.dir_for(:config) (configuration directory). You can override it using rackup option in both init files (because they are already loaded at this point) or using --rackup command line option. ReloadClasses bootloader spawns a thread to check up changed files and reload them. This will be skipped if you set :reload_classes config option to false. Reload time can be tuned using :reload_time configuration option. Both of them, as you already guessed it, are taken from Merb::Config. ReloadTemplates does what ReloadClasses does but for template files. Use :reload_templates configuration option to control this. Development environment assumes you want templates reloading. h3. End of game. In the end of boot process control is returned to Merb::Server.start where Merb.adapter.start is called passing configuration down to Rack adapter.

Editing Merb core boot process

Recent Activity