Date | Commit message (Collapse) |
|
There were some unnecessary lambdas in there
along with some repeated checks.
|
|
Just use the RAILS_RELATIVE_URL_ROOT variable to support it
since probably works on more versions of Rails. Since no
application I've ever deployed has ever used it, I'm not going
to bother supporting it for Rails <2.3, either.
|
|
This removes half-implemented support to disable static file
serving. People interested enough can provide their own
config.ru file to save some stat(2) syscalls, but extra
command-config options just complicate things.
|
|
Makes problems easier to solve if we dump the
exception...
|
|
This allows config.ru to specify listener and
stuff before we setup the application.
|
|
Combining command-line and config file options in a reasonable
manner has and always will be a painful experience.
|
|
This resurrects old code from Mongrel to wrap the Rails
Dispatcher for older versions of Rails. It seems that
Rails >= 2.2.0 support Rack, but only >=2.3 requires it.
I'd like to support Rails 1.2.x for a while, too.
|
|
Loading Rails (or at least config/environment)
will already load its version of Rack, duh!
This also prevents a double-require of Rack
causing redefined Rack::VERSION errors.
|
|
This was broken in the last commit (d1ff8c5):
start libifying common launcher code
|
|
The daemonization logic between unicorn and unicorn_rails
scripts can definitely be shared.
Again: our daemonization logic is slightly non-standard since
our executables are designed to run in APP_ROOT/RAILS_ROOT and
not "/" like "normal" UNIX daemons.
|
|
This should just run inside RAILS_ROOT out-of-the-box. No
config.ru is needed (but we'll use one if it's detected).
This has slightly different semantics than script/server
and the normal "unicorn" script (which has "rackup"-like)
semantics. It tries to combine the best of both worlds,
but do not consider the command-line option interface
to be stable by any means.
|