From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-02-18 18:13:10
>> * Filtering based on logged data. E.g. imagine logging airplane
>> takeoffs and landings and wanting to log only landings for airplanes
>> coming in from Frankfurt.
>> * Filtering log messages so that they end up getting written to only
>> some destinations. E.g. specifying at run-time that you want information
>> about those same airplanes from Frankfurt logged to the output screen
>> while all output, including this one, gets logged to the main network
>> logging server.
> Could you elaborate a little here? Are you implying that the configurability
> of the logging library does not extend to the behaviours described above?
> Or that some canned filters might be provided by the library to ease the
> pain of implementing those behaviours?
> Or are you after something more explicit, i.e. the formalization of the
> logging data say, into columns, and the ability to test presented messages
> by reference to those columns?
You can implement the aforementioned functionality by wrapping the
library's logging calls with your own that then take the input
parameters, and decide whether to log based on them. Then that wrapper
layer can select one of many prepared logger objects or update the
logger's destinations and that way decide where to log the message.
I tried implementing this. It is doable, but just seemed complex.
Note though that I did not have/take the time to go very far into
looking for/design a better way to implement this, so those statements
were not intended as 'constructive criticism'... :-)
Whether it is even possible to make this 'simpler' without
sacrificing other requirements like efficiency, I do not know. Maybe
formalization of logging data could help.... maybe not... I do not have
enough information to decide this. I hope to steal some time soon to
actually try out this library in a real world project and report back my
As I said in the review... this library needs to be grown based on