[OPEN-ILS-DEV] PATCH: log.[ch] (rerouting to stderr)

[Scott McKellar]

This patch makes three unrelated changes to the logging machinery.

1. When we log messages to a log file, we open and close the file
for each message.  If the open fails, we write a message to stderr
about the failure to open, but we discard the original message that
we were asked to issue.

With this patch, after issuing the message about the failure to
open, we write the original message to stderr.

I believe that this change plugs the last message leak.  Now if we're
asked to issue a message, by golly we're going to issue it, one way
or another.

Of course the user may still not see the message, either through
inattention or, for example, because stderr is redirected to
/dev/null.  In that case the user is just a poo-poo head, and I have
no sympathy for him.

2. In an earlier post I proposed to change osrfLogSetType() so that
it would return the previous log type.  That way one could
temporarily change the log type and then restore it later, without
knowing in advance what to restore it to.

Upon further reflection I decided that the only plausible use for
this trick would be to reroute messages to standard error, and I 
might as well provide a mechanism limited to this purpose.

Accordingly I created two new functions and prototyped them in log.h:

osrfLogToStderr() reroutes messages to stderr, and saves the previous
log type internally.

osrfRestoreLogType() restores the log type previously saved, if any.

This interface provides fewer ways for the calling code to mess up
than what I had originally contemplated.  First, the calling code 
doesn't have to keep track of the previous log type.  Second, if the
messages are already rerouted, osrfLogToStderr() will do nothing.  
One needn't worry about nested reroutings, or maintaining a stack of
log types, or anything of the sort.

If we ever need anything fancier we can build it, but I don't think
we will.

3. Wherever a function takes no parameters, I coded "void" as the
formal parameter list.  Otherwise the compiler doesn't know whether
the function takes parameters or not.

Warning: if there's any code out there that passes parameters to 
any of these functions, it will no longer compile.  That's probably
a good thing, even if it causes some unpleasantness in the short run.

Scott McKellar
http://home.swbell.net/mck9/aargh/

Developer's Certificate of Origin 1.1 By making a contribution to
this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated
in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source license
and I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and

(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record
of the contribution (including all personal information I submit
with it, including my sign-off) is maintained indefinitely and may
be redistributed consistent with this project or the open source
license indicated in the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_c_5.patch
Type: text/x-patch
Size: 2728 bytes
Desc: 2343205842-log_c_5.patch
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070626/6c9a08f9/log_c_5.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_h_3.patch
Type: text/x-patch
Size: 1429 bytes
Desc: 1768843763-log_h_3.patch
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070626/6c9a08f9/log_h_3.bin