Hey Scott,
I guess you're right.. if the aggregate logger registers itself for
the application.log event, it will simply stuff those log messages
down into it's contained loggers, regardless of whether they are
listening for this event themselves. Frankly, I think we have
established that symfony
Hi Daniel,
I'm attempting to implement your suggested method of custom logging,
since I have a requirement of logging certain activities in my
application outside the standard log files. I've called my event type
activity.log for reference.
Logging messages of type activity.log works. The
Hello
So instead of $logger-info() I should write something like this?
$this-getEventDispatcher()-notify(new sfEvent($this, 'blah.log',
array('loglevel'='info', 'msg'='hello world'));
Well, that would not exactly be more elegant than:
$logger = BlahLogger::getInstance()-info(hello world);
It's longer perhaps but more elegant? You betcha! It doesn't create a new
dependency in your code because your logger could also *not* be there and the
code would still work.
Cheers, Daniel
On 26.02.2010, at 12:57, Christian Hammers wrote:
Hello
So instead of $logger-info() I should write
Oh, if the logging does not work because classes go lost, I'd rather want the
programm to terminate :)
But thanks anyway, the event handling does not sound uninteresting, maybe I can
use it for something else somewhen.
bye,
-christian-
On Fri, 26 Feb 2010 13:42:08 +0100
Daniel Lohse
What Daniel said..
Plus, for convenience you can always create a local log method on
whatever object you're logging from that wraps the calls to the event-
dispatcher. Then you have elegant and short.
Daniel
On Feb 26, 5:34 am, Christian Hammers c...@lathspell.de wrote:
Oh, if the logging
Hello
But how do I get an instance of this class?
Or maybe we have a misunderstanding: I do not want $this-getLogger()-info()
to log into the default logfile as well as into my custom logfile. I want
separate logfile just for special notes which should also not appear in
the regular log files.
Hey Chris,
you don't need to interact with this logger directly. It just sits
there and listens for your custom logging events.
The dispatcher is what you need to worry about, since that's used to
dispatch the events in the first place. You'll find that the
dispatcher is more available throughout
Hello
Thanks for this hint!
I could not figure out how to use the factory.yml without interfering
with the standard logger as you apparently can't create arbitrary objects with
it.
But after adding the following function:
class BlahLogger {
public static function getInstance() {
Hey Christian,
it's simpler than that.
Look in your factories.yml at the bottom where the loggers are being
set up.
The main logger is an aggregate logger, and you can add your logger to
this like so:
(under loggers)
my_logger:
class: BlahLogger
param:
level: whateverlevel
file:
Hey Christian,
yeah, I've had some trouble with that as well, but I think I found a
good solution.
First, I continue to use the regular event system to send log events,
but I send events of type blah.log instead of application.log.
Now, to catch those you have to implement a custom logger like
11 matches
Mail list logo
