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 problem: even
though ActivityFileLogger unregisters for the "application.log" event
type (after the call to parent::initialize), everything that gets
written to the application log is also being written to the
activity.log file, in addition to the "activity.log" events.
Looking through the framework source, I see that sfAggregateLogger
registers itself for "application.log" events (via parent::initialize)
after adding the specified loggers, though it also unregisters each of
its loggers from "application.log" when adding them. So I'm kind of
at a loss as to why all the application events are getting logged to
my custom log.
Here's what I've got:
class ActivityFileLogger extends sfFileLogger
{
public function initialize(sfEventDispatcher $dispatcher, $options =
array())
{
parent::initialize($dispatcher, $options);
$dispatcher->connect('activity.log', array($this,
'listenToLogEvent'));
$dispatcher->disconnect('application.log', array($this,
'listenToLogEvent'));
}
}
class AuditLogger // wrapper for application code to do the custom
logging
{
// ...
public function logActivity($message)
{
sfContext::getInstance()->getEventDispatcher()->notify(new
sfEvent($this, 'activity.log', array($message)));
}
}
And from factories.yml (I've omitted the default loggers):
all:
logger:
class: sfAggregateLogger
param:
loggers:
activity_log:
class: ActivityFileLogger
param:
file: %SF_LOG_DIR%/activity.log
Any ideas? Is it really advantageous to use this approach, versus just
creating an instance early in the application and using it in the
controller? I'm also thinking in terms of how I'll have to modify
factories.yml to get this custom logging to work in "prod" as well as
"dev" without altering the lack of application logging.
Thanks a bunch for the help you've already provided here!
Scott
On Feb 26, 9:25 am, Richtermeister <nex...@gmail.com> wrote:
> 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 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 <annismcken...@googlemail.com> wrote:
> > > It's longer perhaps but more elegant? You betcha! It doesn't create a new
> > > dependency in your code because yourloggercould 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 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");
>
> > > > bye,
>
> > > > -christian-
>
> > > > On Thu, 25 Feb 2010 10:21:00 -0800 (PST)
> > > > Richtermeister <nex...@gmail.com> wrote:
>
> > > >> Hey Chris,
>
> > > >> you don't need to interact with thisloggerdirectly. It just sits
> > > >> there and listens for yourcustomlogging 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 the application than the
> > > >>loggeris, so stick with events to trigger logging.
>
> > > >> Daniel
>
> > > >> On Feb 25, 9:21 am, Christian Hammers <c...@lathspell.de> wrote:
> > > >>> 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 mycustomlogfile. I
> > > >>> want
> > > >>> separate logfile just for special notes which should also not appear
> > > >>> in
> > > >>> the regular log files.
>
> > > >>> bye,
>
> > > >>> -christian-
>
> > > >>> On Wed, 24 Feb 2010 09:25:45 -0800 (PST)
>
> > > >>> Richtermeister <nex...@gmail.com> wrote:
> > > >>>> Hey Christian,
>
> > > >>>> it's simpler than that.
> > > >>>> Look in your factories.yml at the bottom where the loggers are being
> > > >>>> set up.
> > > >>>> The mainloggeris an aggregatelogger, and you can add yourloggerto
> > > >>>> this like so:
>
> > > >>>> (under loggers)
> > > >>>> my_logger:
> > > >>>> class: BlahLogger
> > > >>>> param:
> > > >>>> level: whateverlevel
> > > >>>> file: path_to_file
>
> > > >>>> That starts thisloggerautomatically, and since it only listens to
> > > >>>> your specialized events, it shouldn't get into the way..
>
> > > >>>> Daniel
>
> > > >>>> On Feb 24, 4:59 am, Christian Hammers <c...@lathspell.de> wrote:
> > > >>>>> Hello
>
> > > >>>>> Thanks for this hint!
>
> > > >>>>> I could not figure out how to use thefactory.ymlwithout interfering
> > > >>>>> with the standardloggeras you apparently can't create arbitrary
> > > >>>>> objects with it.
>
> > > >>>>> But after adding the following function:
> > > >>>>> class BlahLogger {
> > > >>>>> public static function getInstance() {
> > > >>>>> return new NcLogger(
> > > >>>>> sfContext::getInstance()->getEventDispatcher(),
> > > >>>>> array('level'=>'debug', 'file'=>
> > > >>>>> sfConfig::get('sf_log_dir').'/nc.log'));
> > > >>>>> }
> > > >>>>> ... your initialize() ...
> > > >>>>> }
>
> > > >>>>> I can now use it like this:
> > > >>>>> $logger= BlahLogger::getInstance();
> > > >>>>> $logger->info("hello world");
>
> > > >>>>> bye,
>
> > > >>>>> -christian-
>
> > > >>>>> On Tue, 23 Feb 2010 21:22:00 -0800 (PST)
>
> > > >>>>> Richtermeister <nex...@gmail.com> wrote:
> > > >>>>>> 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 acustomloggerlike so:
>
> > > >>>>>> class BlahLogger extends sfFileLogger
> > > >>>>>> {
> > > >>>>>> public function initialize(sfEventDispatcher $dispatcher,
> > > >>>>>> $options =
> > > >>>>>> array())
> > > >>>>>> {
> > > >>>>>> parent::initialize($dispatcher, $options);
> > > >>>>>> $dispatcher -> disconnect('application.log', array($this,
> > > >>>>>> 'listenToLogEvent'));
> > > >>>>>> $dispatcher -> connect('blah.log', array($this,
> > > >>>>>> 'listenToLogEvent'));
> > > >>>>>> }
> > > >>>>>> }
>
> > > >>>>>> You can then instantiate thisloggeranywhere (either by adding it to
> > > >>>>>> your factories.yml file, or instantiating it directly.)
>
> > > >>>>>> Hope this helps.
>
> > > >>>>>> Daniel
>
> > > >>>>>> On Feb 23, 9:14 am, Christian Hammers <c...@lathspell.de> wrote:
> > > >>>>>>> Hello
>
> > > >>>>>>> Is it possible to define acustomsfFileLogger() in factories.yml
> > > >>>>>>> that works
> > > >>>>>>> completely independend from the standard frontend.log? It should
> > > >>>>>>> be accessed
> > > >>>>>>> like e.g. sfContext::getLogger("myAppLog")->info("remember that");
> > > >>>>>>> Just that getLogger() does not take an argument and I'm probably
> > > >>>>>>> trying it
> > > >>>>>>> the completely wrong way again :)
>
> > > >>>>>>> bye,
>
> > > >>>>>>> -christian-
>
> > > > --
> > > > If you want to report a vulnerability issue on symfony, please send it
> > > > to security at symfony-project.com
>
> > > > You received this message because you are subscribed to the Google
> > > > Groups "symfony users" group.
> > > > To post to this group, send email to symfony-users@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > symfony-users+unsubscr...@googlegroups.com
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/symfony-users?hl=en
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
