Deb Lewis
2006-Jul-30 18:31 UTC
[Masterview-devel] Why your logging in Initializer#initialize_configuration didn''t work
initializer.rb method initialize_configuration(lines 715-715): # this logging didn''t seem to work?? # @log_msg_q << [ :info, ''Program name = ''+$PROGRAM_NAME ] # log the program that is starting That didn''t work because there''s still some excessively tricky back-and-forth between how the initalizer gets run in the normal scenario when app [rails plugin] startup loads masterview.rb and a backstop for non-standard init scenarios in which the initializer gets run explicitly. (and reporting bad directive_path entries, the original reason I invented that @log_msg_q gadget, also didn''t work; ain''t testing a grand idea) Fixed by reworking the way early-init messages are recorded and installing the logger a bit earlier in the init process (do right after MV itself is loaded, before the MIO init or any other startup processing) ~ Deb
Jeff Barczewski
2006-Jul-31 03:22 UTC
[Masterview-devel] Why your logging in Initializer#initialize_configuration didn''t work
great! I was thinking of logging the program name so that it would be easy to fix a problem if masterview was not being loaded if brought up in a new environment (not webrick, lighttpd, fcgi, scgi). The way things work we need to know the program name. However if possible I would like to find a better way that looks for something defined and not just the program name. I haven''t been able to find the right thing yet. So for the apache scgi patch I just added more to the program name match. On 7/30/06, Deb Lewis <djlewis at acm.org> wrote:> > initializer.rb method initialize_configuration(lines 715-715): > > # this logging didn''t seem to work?? > # @log_msg_q << [ :info, ''Program name = ''+$PROGRAM_NAME ] # log the > program that is starting > > That didn''t work because there''s still some excessively tricky > back-and-forth between how the initalizer gets run in the normal scenario > when app [rails plugin] startup loads masterview.rb and a backstop for > non-standard init scenarios in which the initializer gets run explicitly. > > (and reporting bad directive_path entries, the original reason I invented > that @log_msg_q gadget, also didn''t work; ain''t testing a grand idea) > > Fixed by reworking the way early-init messages are recorded and installing > the logger a bit earlier in the init process (do right after MV itself is > loaded, before the MIO init or any other startup processing) > > ~ Deb > > > _______________________________________________ > Masterview-devel mailing list > Masterview-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060730/b75230dc/attachment.html