Post by Sebastian KuleszPost by Sebastian KuleszI just commited an update to the gb.logging component. Please note that a
call to Logger.Begin() is no longer necessary and will fail. The log is
automatically opened for writing when creating the logger.
A recent change, too, is the ability to use the component without
creating
Post by Sebastian Kulesza Logger instance. If you call Logger.Log(...) a new, hidden instance
will
Post by Sebastian Kuleszbe created for you. This is useful if you only need one Logger and use it
in multiple Modules/Classes of you application. It will save you a public
variable and a few LOC.
Grraaaaaagh! I just spent several hours working up a solution for
logging to a single log across multiple components/libraries.
One question, is there any change to the parameters? AKA where does the
log info get sent to when using the hidden instance?
The first time you use it, it will create the hidden instance with the
default values. As it was standing, it was impossible to change the output
of the logger, as it could only be set when creating an instance and by
default it was Stdout.
So, in the new revision you can change the format, level and output using
the logger properties. I was forced to add the Begin() call again (Sorry
about that). Once this function is called, Logger.Output can't be changed.
Post by Sebastian KuleszPost by Sebastian KuleszAlso, it is now possible to redirect the Logger output to stderr ;)
Hope you like it! Please let me know any thoughts!
I have been thinking (hard to believe!) about some kind of scheme for
logging to multiple files. Some ideas were to
a) use the cron approach i.e. 3 logs "error", "info" and "warning" but
probably "error", "info" and "debug" would be better suited to a
development system like Gambas.
b) similar to a) but allow configuration as to what level message goes
to which log.
Here on our production stuff we really need to keep errors & warnings
very separate from the info log(s) as they need high visibility (i.e. if
error.log is not empty then everyone panic!), the "info" logs are of two
types, general "this got done and that got done and this is what came
out" data and audit data (bluh!) and we really need the "debug.log" on
the dev/fix side of things.
Remember you can output wherever you want and set a custom format. What i
recommend you, depending on your setup, is to either output to a file and
monitor it for changes. When one is found you look for the debug name using
regexp (remember, custom format) and copy that line to another file of your
choice. Or to pipe the output of your application to a bash script which
will scan the log for it's level name and append it to a file of your
choice.
Post by Sebastian KuleszThe other thing I would like to see is a way to increase the number of
levels of detail once we get down to the "debug" level. This would be on
an application basis.
Done! Level can now be greater than Logger.Debug. The $(levelname) tag will
now be replaced by CUSTOM DEBUG in this case. You can use it in conjunction
with $(levelno) to describe the debug level.
Post by Sebastian Kuleszcheers
Bruce
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user