[Gambas-user] gb.logging API change

[Sebastian Kulesz]

On Mon, Dec 16, 2013 at 3:15 AM, Bruce <bbruen at ...2308...> wrote:

> On Mon, 2013-12-16 at 01:14 -0200, Sebastian Kulesz wrote:
> > I 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
> > a Logger instance. If you call Logger.Log(...) a new, hidden instance
> will
> > be 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.


>
> >
> > Also, 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.



>
> The 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.



>
> cheers
> 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
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>