[hunchentoot-devel] Logging API and default behavior changed
Hi, I have made an incompatible change to Hunchentoot's logging API (http://bknr.net/trac/changeset/4639). To sum up: The old special variables to configure the log paths as well as the -logger slots in the acceptors are gone. Instead, Hunchentoot now has per-acceptor slots containing the log pathnames, if any. Logging is performed by calling the ACCEPTOR-LOG-ACCESS and ACCEPTOR-LOG-MESSAGE generic functions that can be specialized for derived logger classes. Previously, it was possible to disable logging altogether by setting the log pathnames to NIL, which also was the default. I have changed that so that if a log pathname is NIL, the log entry is written to CL:*ERROR-OUTPUT* instead. This seems to be a more helpful behavior. If an application desires to switch off logging completely, it now needs to either set the log pathnames to "/dev/null" (wasteful, but quick) or implement methods for the logging functions above. Please let me know if there are any problems with this change, apart from the incompatibility. -Hans
On Sun, Jan 23, 2011 at 01:49, Hans Hübner <hans.huebner@gmail.com> wrote:
Previously, it was possible to disable logging altogether by setting the log pathnames to NIL, which also was the default. I have changed that so that if a log pathname is NIL, the log entry is written to CL:*ERROR-OUTPUT* instead. This seems to be a more helpful behavior. If an application desires to switch off logging completely, it now needs to either set the log pathnames to "/dev/null" (wasteful, but quick) or implement methods for the logging functions above.
I think that binding CL:*ERROR-OUTPUT* to an empty broadcast stream should also work for disabling logging. But that will still have the performance cost of writing to a stream; overriding the methods seems like the better choice for deploying code somewhere. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs
Hans, Hans Hübner wrote:
Hi,
I have made an incompatible change to Hunchentoot's logging API (http://bknr.net/trac/changeset/4639).
To sum up: The old special variables to configure the log paths as well as the -logger slots in the acceptors are gone. Instead, Hunchentoot now has per-acceptor slots containing the log pathnames, if any. Logging is performed by calling the ACCEPTOR-LOG-ACCESS and ACCEPTOR-LOG-MESSAGE generic functions that can be specialized for derived logger classes.
Definitely a good change. Just to make sure, the old special variables only mattered if you used the default logger functions, right? In our system, we always provide our own logger functions, so those special variables were not used, as far as I know. The per-acceptor slots containing the log pathnames are used by the default methods, and are available for custom (subclass) methods, but have no effect if you provide your own methods that do not use them, right? I'm just checking to be sure. -- Dan
Previously, it was possible to disable logging altogether by setting the log pathnames to NIL, which also was the default. I have changed that so that if a log pathname is NIL, the log entry is written to CL:*ERROR-OUTPUT* instead. This seems to be a more helpful behavior. If an application desires to switch off logging completely, it now needs to either set the log pathnames to "/dev/null" (wasteful, but quick) or implement methods for the logging functions above.
Please let me know if there are any problems with this change, apart from the incompatibility.
-Hans
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Mon, Jan 24, 2011 at 10:19 PM, Daniel Weinreb <dlw@itasoftware.com> wrote:
Just to make sure, the old special variables only mattered if you used the default logger functions, right? In our system, we always provide our own logger functions, so those special variables were not used, as far as I know.
Correct.
The per-acceptor slots containing the log pathnames are used by the default methods, and are available for custom (subclass) methods, but have no effect if you provide your own methods that do not use them, right?
That is correct as well. While implementing the change, I have actually pondered the possibility of creating a mixin class for the logging behavior or create a logger class right away, but found that to be of little immediate value given that the acceptor class has several other slots that are useful only in certain operating modes. -Hans
participants (3)
-
Andreas Fuchs -
Daniel Weinreb -
Hans Hübner