Below is a current logging.ini representing what we've been talking about. After giving it some thought this weekend, I came to the decision that I don't want "Appenders" to be making decisions about what to append and what not to append. Therefore, all the "decisions" in that department should be left to the Loggers. By default, this means that the Logger class will accept a min_priority and a max_priority ... and any message that shows up with a priority between those will be passed onto any Appenders registered with that Logger.
Of course this leaves the door wide open for extending the entirety of the logging framework, be it Logger, Appender, Message or Layout. You could, for instance, have a Logger that filters Messages based on Context.. something we had decided should be possible. With this layout solidified in my brain, I also see that we should be using the Observer pattern.. not only within Logger, but also within LoggerManager.. making a call to LoggerManager::log() send the Message to all registered loggers, and thus eliminating the need to specify which logger to send it to. Again, discussion requested :) --Bob ===== BEGIN logging.ini ===== [loggers] ;default = DefaultLogger ;error = ErrorLogger ;[DefaultLogger] ;class = Logger ;appenders = "InfoSyslogAppender, MyAppLogAppender" ;param.min_priority = INFO ;[ErrorLogger] ;class = Logger ;appenders = "ErrorSyslogAppender, MyAppErrorLogAppender" ;param.min_priority = ERROR ;[InfoSyslogAppender] ;class = SyslogAppender ;layout = PassthruLayout ;param.priority = LOG_INFO ;[ErrorSyslogAppender] ;class = SyslogAppender ;layout = PassthruLayout ;param.priority = LOG_ERROR ;[MyAppLogAppender] ;class = FileAppender ;layout = PassthruLayout ;param.file = "%AG_WEBAPP_DIR%/log/myapp.log" ;[MyAppErrorLogAppender] ;class = FileAppender ;layout = PassthruLayout ;param.file = "%AG_WEBAPP_DIR%/log/myapp_error.log" ===== END logging.ini ===== On 7/2/05, David Zülke <[EMAIL PROTECTED]> wrote: > > You're using observers, if I understand it correctly, it's just that > > you're taking some of their responsability and transfering it to the > > manager. And I think the YAGNI you see is actually the code in the > > mirror (oh! back atcha!). Seriously, we have multiple implementations > > in other areas of the framework, why's there need to be one logging > > system to rule them all? > > We -could- implement both, yea? > > Hooray! > > > > > Obviously I'm not rushing into any of this ;) I know Mike's on > > > vacation until Tuesday, but maybe we can all argue about this in IRC > > > at some point =) > > > > Right and I wont be around a computer either. :) > > > > So I'll see ya'll in a few days. > > Have fun! > > - David > > > _______________________________________________ > agavi-dev mailing list > [email protected] > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev > _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
