Interesting is also this page http://guides.rails.info/configuring.html
which states under "2.Running Code Before Rails": To run some code before
Rails itself is loaded, simply put it above the call to require 'rails/all'
in your application.rb.

If I log boot strapping of rails, I get this different sequences:

when using mongrel via script/server (notice boot.rb appears twice!!!):
 boot.rb
 environment.rb
 boot.rb
 application.rb

when using mongrel via mongrel_rails:
 environment.rb
 boot.rb
 application.rb

Note that while the latter option is the common way to start the
application, the former option is what I must use to debug my rails
application under Netbeans. 

So clearly, running code (that fetches custom specific command line options)
before rails starts doesn't work well with either environment, let alone
both.

I've even tried to place such code inside environment.rb which is clearly
loaded before application.rb and still had no luck.

So far, the only way that worked for me is to modify library code and this
is something a dread.

Pete

-----Original Message-----
From: mongrel-users-boun...@rubyforge.org
[mailto:mongrel-users-boun...@rubyforge.org] On Behalf Of Pete
Sent: Wednesday, 14 April 2010 8:35 a.m.
To: mongrel-users@rubyforge.org
Subject: [Mongrel] Mongrel script and config options

I need to pass some startup options on to my rails application. Using
environment variables will not work because multiple mongrel clusters of my
rails application (each of a slightly different flavour) served from a
single code base can run concurrently and each cluster instance is activated
via mongrel_service.

Extra arguments passed in to either mongrel_rails service::install or
mongrel_rails cause errors.

The only documentation on the --script option I could find related to unix
so I gave up on that thought.

I also tried using the --config option, but I had the same problem there: as
soon as I added an option to the YAML file that wasn't documented, mongrel
complained with an error.

The last one is a real nuisance. It just doesn't make sense that my config
file should be restricted to content mongrel understands. Wouldn't it be a
better approach to parse that file and look/apply the options mongrel
recognises and provide a public interface so that other interested clients
can access the config file?

Or are there other ways to achieve this without resorting to modifying
mongrel and mongrel services startup code?

Pete

_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users

Reply via email to