Logging facility for GNU-smalltalk

Hello,

in the last week, I created a small logging facility which could be used
with GNU-smalltalk. (Because I haven't found something like the logging
api from Java for Smalltalk and I was tired using 'xyz' printNl's. ...)

I don't know, if you have a usage for it, or if you in generall
interested in it, but please allow me to describe it a little bit.

--

For reading the bit of documentation, please visit:
http://www.joachim-jaeckel.de/redmine/wiki/log4gst

For the case, you would like to download it, try:
svn co svn://www.joachim-jaeckel.de/repos/log4gst/trunk Logging


It consists of a LogManager, which is available via Log4Gst.LogManager
instance. It's implemented as a singleton, so there's only one instance
in a smalltalk-vm.

This LogManager can handle different instances of loggers (available via
logManager logger: 'CategoryXYZ'). These loggers are identified through
category-names. (The idea behind is, that e.g. if you have several
different applications running in the same vm, that every application
could have it's own logger...)

Each logger itself can have different output "channels", these
"channels" could be constructed via an output-handler (like a
transcript-output-handler or a file-output-handler) and a special
formatter (like a text-formatter or a html-formatter).

This gives you the possiblity, to log directly with a text-format to the
transcript and parallel in html-format to an html-file. Or you could
subclass your own output-handler and formatter and provide some
completely new outputs and formats of the messages.

There exists 6 different kind of messages, which could be printed.
(SEVERE, WARNING, INFO, FINE, FINER, FINEST).
(Additionally, there are defined NONE and ALL, where ALL means the same
as FINEST...)

For the logger and for every configured channel, you can set the
output-severity of them independently.
The severity which could be set for the logger itself, controls the
output of messages, which should be printed in general through this
logger. The severity which could be set for each channel, controls the
output of messages, which should be printed through this channel.

A log-message is automatically enhanced by the category of the logger,
the date and time of printing the log-message, and the class and
method-name, from which the logging is called. Of course, you can
control the information which is printed through several different
implementations of the different formatters, or write your own one.

Best regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> This gives you the possiblity, to log directly with a text-format to the
> transcript and parallel in html-format to an html-file. Or you could
> subclass your own output-handler and formatter and provide some
> completely new outputs and formats of the messages.

Very nice.  It could be used for SUnit too...

> There exists 6 different kind of messages, which could be printed.
> (SEVERE, WARNING, INFO, FINE, FINER, FINEST).

What about CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG/ALL (these are
six of the eight loglevels used by Linux, see man syslog).

I have no connectivity as I'm writing this, did you write some
testcases?  With them, I would seriously consider including it in the
tarball.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hello Paolo,

thanks for your reply, I already though, that there's not much interest
in logging in the smalltalk-group. (Beside, I only found a small
logging-tool for squeak and an html-logger for VW.)

> What about CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG/ALL (these are
> six of the eight loglevels used by Linux, see man syslog).

Ok, my first intention was to name it like the ones in the java-logging,
(but I don't realy like the fine, finer, finest naming). I'll switch it
to the naming recommended by you.

> I have no connectivity as I'm writing this, did you write some
> testcases?  With them, I would seriously consider including it in the
> tarball.

I assume, you need some SUnit Testcases?

(I have included only an ugly Test.st, which only gives some comments
like "you should now only see 'xyz' log-messages" or "please control the
test.html file that it contains only the log-messages for xyz severities".)

Regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I assume, you need some SUnit Testcases?

Yep.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

I'll do my best...

Paolo Bonzini schrieb:
>
>> I assume, you need some SUnit Testcases?
>
> Yep.
>
> Paolo
>
>



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> What about CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG/ALL (these are
> six of the eight loglevels used by Linux, see man syslog).

Ops, as I made the changes, the following attracted my attention...:

Do you think, that "error" like "logger error: 'an error occured!'"
would be a good idea?


(or should error renamed maybe to SEVERE?)

Regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/08/2009 03:47 PM, Joachim Jaeckel wrote:
>> What about CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG/ALL (these
>> are six of the eight loglevels used by Linux, see man syslog).
>
> Ops, as I made the changes, the following attracted my attention...:
>
> Do you think, that "error" like "logger error: 'an error occured!'"
> would be a good idea?

No. :-)

> (or should error renamed maybe to SEVERE?)

Hmmm, but an error is an error...

Do you really not like logCritical: logError: logWarning: etc?

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Sorry for the delays in my replys!

> No. :-)

;-)

> Do you really not like logCritical: logError: logWarning: etc?

It's somehow not my favourite, but I will go with it!

For the SUnit-tests, I thought of writing to a log-file and control the
entries afterwards, would that be okay?

Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> For the SUnit-tests, I thought of writing to a log-file and control the
> entries afterwards, would that be okay?

That, or maybe you can pass an arbitrary stream?

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 8 Jul 2009 23:38:29 +0200
Paolo Bonzini <[hidden email]> wrote:

> > For the SUnit-tests, I thought of writing to a log-file and control
> > the entries afterwards, would that be okay?
>
> That, or maybe you can pass an arbitrary stream?

Not maybe, definitely!

Logging should always go to a stream and not be hardwired to
assume files. Let the user decide what he wants to do with the
logging data.

And it is much easier to test:

logger logSomething: 'whatever'.
logger logStream contents == 'whatever'

You don't want to test that reading and writing a file works,
that's Paolo's job :-)

Also, one could implement a "tee" like functionality, i.e.
duplicating the log output on both stdout and a file. Or even
piping it (eg via nc) to a remote location.


>
> Paolo
>
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk
>


--
Stefan Schmiedl
EDV-Beratung Schmiedl, Berghangstr. 5, D-93413 Cham
im Büro: 09971 9966 989, am Handy: 0160 9981 6278


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> That, or maybe you can pass an arbitrary stream?
>
> Not maybe, definitely!

The functionality definitely has to be there.  "Maybe" Joachim already
had it. :-)

> Also, one could implement a "tee" like functionality, i.e.
> duplicating the log output on both stdout and a file. Or even
> piping it (eg via nc) to a remote location.

Note that however the logger should not hardcode streams either (at
least in the future).  For example a hypothetical SyslogLogger would
prefer to log independently, without using an arbitrary stream.

This however can wait.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi Stefan,

maybe I got you wrong (if that's the case, please excuse),

> Logging should always go to a stream and not be hardwired to
> assume files.

Does that mean, that the user who uses the logging-functionality should
care about handling the stream?

I don't think so. Logging should be less user-interactive as possible in
my opinion. (And configurable to fullfill the needs of the programmer.)

Logging to a stream should be an option in my opinion but not the usual
case...

> And it is much easier to test:
>
> logger logSomething: 'whatever'.
> logger logStream contents == 'whatever'
>
> You don't want to test that reading and writing a file works,
> that's Paolo's job :-)

That's something where I absolutely agree!

> Also, one could implement a "tee" like functionality, i.e.
> duplicating the log output on both stdout and a file. Or even
> piping it (eg via nc) to a remote location.

That's something, what I would like to see in the logging interface.

Regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> The functionality definitely has to be there.  "Maybe" Joachim already
> had it. :-)

A StreamOutputHandler is currently not included, but after the post of
you and Stefan, I think it should be there.

And a OutputHandler to syslog or to a socket was something which already
came to my mind, but that has not such a high priority for me at the
moment...

Regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> maybe I got you wrong (if that's the case, please excuse),

No problem, discussing and misunderstanding is the best way to come up
with new ideas.

>> Logging should always go to a stream and not be hardwired to
>> assume files.
>
> Does that mean, that the user who uses the logging-functionality should care
> about handling the stream?

First of all, let's clarify that we never talk about the user of the
application, just the user of the logging component (so "user" and
"programmer" are the same person).

In this I agree with Stefan.  It's okay to have a method to quickly
create a logger that writes to a file.  However, this should be just
one of three ways:

1) writing to a file

2) writing to an arbitrary stream

3) a logger created with "Logger new" finally should write either to
"String new writeStream", or to a singleton stream stored somewhere
(in a class variable?).

1 and 3 should be delegating to 2.

> Logging to a stream should be an option in my opinion but not the usual
> case...

That does not mean that the "usual cases" shouldn't be implemented in
terms of it.  Logging to a stream is the basic low-level option, and
every other constructor for loggers should simply create the
appropriate kind of stream.

>> Also, one could implement a "tee" like functionality, i.e.
>> duplicating the log output on both stdout and a file. Or even
>> piping it (eg via nc) to a remote location.
>
> That's something, what I would like to see in the logging interface.

No, that's something that can be useful outside logging, so it must be
implemented as new kinds of stream.

Streams are an exceptionally powerful construct.  All of zlib, iconv,
sockets are based on the abstraction of streams.  For example the
"pipe via nc" case can be realized very easily by just passing a
connected socket to the logger... as a stream!

Answering your other email, I admit I haven't read the code but it's
good that you have output separate from logging.  Now try making the
file output handler just use a StreamOutputHandler.  The changes will
be extremely small, trust us, and will include the socket case for
free.

I would even say that 99% of the output handler's task is to format
the output (so you can have HTML, text, etc. handlers).  The syslog
handler would be pretty much the only handler I can imagine that
cannot work on an arbitrary stream.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, 09 Jul 2009 09:27:59 +0200
Joachim Jaeckel <[hidden email]> wrote:

> maybe I got you wrong (if that's the case, please excuse),

maybe I blubbered incoherently, so please excuse me for not being clear.

> > Logging should always go to a stream and not be hardwired to
> > assume files.
>
> Does that mean, that the user who uses the logging-functionality
> should care about handling the stream?
>
> I don't think so. Logging should be less user-interactive as possible
> in my opinion. (And configurable to fullfill the needs of the
> programmer.)

As user of the logging facility (i.e. application programmer), I'd like
to be able to write logging information
 - to a file, eg something like Logger onFile: aPath, where I want to
   decide on whether the file is being replaced (session log) or appended
   (audit log)
 - to a string, so that I can easily display it in my application, eg
   when showing the results of a batch process
 - synchronously or asynchronously
Since I know what should happen to the log, you either need to provide
for all my potential needs, a battle which you're bound to lose, or you
simply refuse to take the responsibility for something that lies beyond
your domain and leave it with me.

Hence my idea of what a logging facility should support: streams.

When I open the log file, *I* decide whether to overwrite or append,
the logger uses the properly configured stream. When I want the log
as a string, *I* give you a "String new writeStream". When I really
need buffered logging, it should be *my* job to provide a flush method
which defers to a buffer manager for actually writing the data out.

So, ideally, your logger will require a duck quacking "nextPutAll:"
and "flush" and that's it. You will have a slim core functionality,
which I can plug into whatever I want.

s.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> Also, one could implement a "tee" like functionality, i.e.
>>> duplicating the log output on both stdout and a file. Or even
>>> piping it (eg via nc) to a remote location.
>> That's something, what I would like to see in the logging interface.
>
> No, that's something that can be useful outside logging, so it must be
> implemented as new kinds of stream.

I correct myself.  A multiplexing output handler can be useful in case
you want to send HTML to a file and text to stdout.  This is orthogonal
to having a multiplexing stream

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi! Sorry for the delay in answering, I'm just back to the keyboard, but
only for a few minutes...

I now totaly agree, that a StreamOutputHandler is more than usefull.
That gives the user the possibility to handle his special needs beside
of that what is implemented in the current logger. - But even now, it
could be implemented and give it to the implementation of the logger as
the output-handler of a new "channel". But nevertheless, a
StreamOutputHandler should be contained in the logger. Even as a
superclass for File-output-handling and whatever.

But as I understand, it seems to me, that we use the logging a bit
different. (Please don't understand me wrong, the discussion is really
interesting for me!)

Logging (for me) should be a black box. I don't care, to what my logging
is written and if I need a special action at the start/end of the
logging. (e.g. opening/closing the log-file, Flushing the output or:
writing the log as an html-file, you need some closing </body></html> at
the end of the log-file) beside of a configuration-file, which could be
altered without rewriting program-code.

Time is running...

Would be nice if we end up with a logging-utility, that serves most of
our all needs...

Regards,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 07/09/2009 01:50 PM, Joachim Jaeckel wrote:
That's the point -- the file-output handler is not a subclass, it's the
same StreamOutputHandler just that it is created with a different class
method that takes care of creating the FileStream.

 > Logging (for me) should be a black box. I don't care, to what my
 > logging is written and if I need a special action at the start/end of
 > the logging. (e.g. opening/closing the log-file, Flushing the output
 > or: writing the log as an html-file, you need some closing </body>
 > </html> at the end of the log-file)

Agreed, that's the point of the output handler no?  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?

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Joachim Jaeckel (2009-07-09 13:50):

> Hi! Sorry for the delay in answering, I'm just back to the keyboard, but  
> only for a few minutes...

same here ... it's obviously one of those days.

> StreamOutputHandler should be contained in the logger. Even as a  
> superclass for File-output-handling and whatever.

yep.

> But as I understand, it seems to me, that we use the logging a bit  
> different. (Please don't understand me wrong, the discussion is really  
> interesting for me!)

Don't worry about that, everybody around here is very friendly.
If you were not listening and calling us names for doing this
different from you, that swould be something else...

> Logging (for me) should be a black box. I don't care, to what my logging  
> is written and if I need a special action at the start/end of the  
> logging. (e.g. opening/closing the log-file, Flushing the output or:  
> writing the log as an html-file, you need some closing </body></html> at  
> the end of the log-file) beside of a configuration-file, which could be  
> altered without rewriting program-code.

ah ... so you're running a Logger asConfiguredIn: aPath. Nice idea.
That's basically something to decorate a FileLogger with, and is a
perfect fit for the way you are using your code.

Now me, I'm coming from a different direction: I see you developing
a potentially extremely useful library that is being well received, too.
Now is my chance to speak, to discover why the code is done the way it
is, how you intend it to be used, and, finally, to challenge your
assumptions with my own.

Now we're discussing, throwing ideas back and forth, doing so in a
very civil manner (with too much premature apologizing for maybe
stepping on somebody's toes :-). That's great, that's what this
list is here for.

> Time is running...

... and still I'm waffling on ...

> Would be nice if we end up with a logging-utility, that serves most of  
> our all needs...

The Logger To End All Logging, got a ring to it :-)

s.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini (2009-07-09 14:02):

> Agreed, that's the point of the output handler no?  My idea of the class  
> hierarchy would be:
>
>   OutputHandler
>     StreamOutputHandler
>       TextOutputHandler
>       HTMLOutputHandler
>     SyslogOutputHandler

I don't know anything about how to talk to a syslogd. Why can
SyslogOutputHandler not be a StreamOutputHandler?

> What do you think?

I'd like to throw the idea of a filter chain into the discussion.
Something similar to what I think you can do with apache nowadays.
Or what Seaside does with component decorations.

Want your messages plain text? That's the default.
As HTML? Use a HTMLFiter.
Have them spelled backwards? Go develop your ReversingFilter yourself.

In this scenario, the mechanics of logging (i.e. writing onto a stream,
talking to a remote syslogd, whatever) would be separate from content
management.

It might also be possible that I'm talking about exactly the same thing
as Paolo, only with different words.

Curious,
s.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk