[Help-smalltalk] Re: Logging facility for GNU-smalltalk

[Joachim Jaeckel]

Paolo Bonzini schrieb:
> My idea of the class hierarchy would be:
>
>   OutputHandler
>     StreamOutputHandler
>       TextOutputHandler
>       HTMLOutputHandler
>     SyslogOutputHandler
>     MultiplexOutputHandler
>
> (Of course not everything needs to be there to include the logging in gst).
>
> What do you think?

Hi!

Ok, here I see, that an OutputHandler for you is the combination of (in 
the case of my logging currently implemented) a formatter and an Output 
(or Log-) Handler. (Which is called "channel" in my current 
implementation. This is currently not an Object, just a Dictionary with 
the fields for outputSeverity, logHandler and formatter).

I think I should explain in short, how my logging is currently working.

A logger for a category could have several output-channels, which could 
be active for the same time. (if you have several channels active 
[output-severity > NONE], a single log-message is printed on each of the 
channels).

Each channel is a combination of a LogHandler (currently to a File or to 
the transcript, in future even to a stream) and a selected formatter 
(text or html-format currently) you can combine the formatter and the 
logHandler as you like, so that you could log in html to the transcript 
or (with the stream) to a socket. (Or you'll could handle the stream by 
your own).
(or you can implement your own logHandler or formatter and provide an 
instance of it to the channel)
The formatter accepts a LogEntry-Object(*) as the input and returns a 
string of the log-information. The logHandler accepts the string and 
direct it to the desired output.
So the code of the log-message output for each channel is like this:

logHandler log: (formatter format: logEntry).

(Ok, there's additionally a switch for determine, if the output to this 
channel has already started, for the start and end work for each 
formatting and output, but that's only a detail...)

- Do you think, that this what currently is implemented as only a 
Dictionary should go into the former mentioned class-hierachy of objects?

- Maybe I would need some more information, of how you think the 
decorators should work...

(*)
The log-method itselfs creates eventually an Object (I would say a 
ValueObject) with the information of the message.

The call would be: "logger logError: 'This is an error'." and the 
log-method would generate an Object with the infos:
- category
- date
- time
- severity
- classname in which the logError was called  ---
- methodname in which the logError was called    |
- filename                                       |
- line                                            > got from the context
- lineInFile                                     |
- message                                     ---


(Hope I haven't wrote too much...)

Regards,
Joachim.