Early review of std.logger

[Robert Schadek]

On 10/16/2013 01:34 AM, Jeremy Powers wrote:
> On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
> wrote:
>
>     One note - log4j, log4cxx, and log4cpp are not part of the
>     respective languages' standards. That doesn't mean much (in fact
>     it may be a competitive advantage to integrating log4d in std) but
>     it is one factor to consider.
>
>
> It also gave rise to slf4j, to tie the various (java) logging
> solutions together.
>
> From a core library standpoint, the slf4j model might be a good one to
> emulate - provide a basic logging abstraction that can then be plumbed
> to whichever logging implementation is needed.  Logback is essentially
> the logging framework written by the slf4j guys, which is why I used
> it as an example.
>
> And though I am not Eric, I do have a short list.  These are things
> that log4j/slf4j/etc provide that I'd consider required of any log
> framework before I use it in a production* environment:
>
> Multiple log destinations (sinks/appenders), configurable.
>   - required for logging to file, syslog, etc as appropriate
>   - different running instances of same code may need different log
> names/locations/appenders
MultiLogger is planed.
>
> Hierarchical logs, with inheritance of levels, configure at runtime.
>  Turn on/off log level for part of hierarchy.
>   - for debugging own code without being overwhelmed with log
> statements from elsewhere
>   - turn off extraneous logging in dependencies, or turn it on for
> deep diving
no hierarchical logs, KISS just create a logger with different
destination. new FileLogger("myDevLog"); $ tail -f myDevLog
>
> Configurable log ouput with custom fields (time, thread, etc).
>   - required for making log output match predefined formats
>   - include needed metadata in the log line
I think this has been discussed twice already, no configuration can
anticipate all possible needs and will fail fast and hard. So why try, I
rather write 7 lines, than wait for a patch to the configuration parser
to appear in my production env.
>
> Allow 'lazy' evaluation/formatting of log output (parameterized
> logging equivalent).
>   - no performance excuse not to log
>
> Log rotation
>   - if this isn't there out of the box, guarantee will be first
> customization
see above argument
>
>
> * where 'production' is biased towards high availability services
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131016/f33578a1/attachment.html>