I currently use Log4Perl with C::A but I'm sure that even though it's not a via plugin, I'm using it in an inefficient manner - any advice appreciated.
In my base class, I set up the name of my config file using CGI::Application::Plugin::ConfigAuto. I my prerun mode I go
Log::Log4perl::init( $self->cfg('logger_conf') ); $self->{logger} = get_logger("cms");
So whenever I want to log I go
$self->{logger}->debug("my debug message"); $self->{logger}->error("uh oh");
Is the way I am doing things expensive?
No, that looks ok to me. Just make sure that when you are using variables in your log statements (especially if you are dumping vars, etc) that you use the is_debug() and is_error() methods before hand. This will make sure that no interpolation/expansion, etc is done if the log message isn't going to be logged.
>I guess I don't get lazy loading,
but then again, log messages are sprinkled everywhere, so maybe lazy loading is of no advantage to me. To be honest, I've used almost every C::A plugin out there, under the assumption that the plugin is going to do things more efficiently for me than using the underlying (config, dbh, session) packages directly. In other words I use them because I think I should, without knowing why (other than the advantage of lazy loading). For instance, if there was a C::A::P::Log4Perl plugin, what would be the benefits?
I would think that with most plugins there is actually a very slight performance hit as opposed to using the modules directly. There are benefits however...
+ ease of use - most if not all of the plugins should make several things transparent to the user and reduce the number of lines you need to code.
+ best practices - the module author *should* be making sure that things are done in the best possible manner in the other modules he is using.
+ consistency - If you are using plugins in all of your apps, then you don't have to roll project specific code for things like session, logging, configuration unless you really need to. If this is done as a policy (in a workplace for example) then it's easier for other developers as well.
+ sharing - I think that the emergence of plugins has helped all of us to share ideas and implementations with everyone else on this list, and this should only increase.
(On a side note, I must say that I really love Log4Perl and use it
everywhere. I like the way I can change the logging method to screen, db,
email or all three in the config file without a single change in my code,
and I also like the way it can use Log::Dispatch modules like
Log::Dispatch::FileRotate - which has suddenly made half of my log file
housekeeping scripts redundant).
I agree. I would also add some other dispatchers, like Log::Dispatch::Spread and Log::Dispatch::DBI.
If you are interested, I've been meaning to make a CAP::Log4perl plugin but haven't had the time just yet. I will in a few days though. If you wanted to you could take a shot at it yourself. Else, I will hopefully have one by the end of the week.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
