Am 13.01.2015 um 10:54 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

Log4j types of logging systems do a reasonable job at capturing log entries, but they are poor at helping the human make sense of the produced log. Of course, they do attempt, but given that they see the log as a long string, there is a significant mechanism built around formatting.

This is broken because it implies that the human should read the log as a way of understanding it. This works fine for a couple of lines but fails miserably for even Mb logs (not to mention larger logs). One could tweak the formatting to make it machine readable, but in practice all logs I have seen in enterprise systems are mostly unstructured and one has to spend great effort to extract the useful information out of them. For example, I use the information in logs to understand performance and diagnose errors, and I am using automatic tools for that. But, to build those tools, the hardest part is to parse the log. That cost should not exist.

The object as an item of logging preserves the original information so that the machine can read it. String is just a way of serializing an object, and we should only use it only in this way. Formatting still has a place, but it should be clear that it is just one tool - most often the least useful one. That is the reason why in Beacon, there is no formatting in the core.

Priority is another thing I find rather artificial. For example, developers should mark as DEBUG things that are not useful in production, but in the end, they mark as DEBUG things that are too large to have in production all the time. The problem with this is that sometimes you really want to have access to a very specific event regardless of "priority". So, a better way of looking at filtering is by allowing the developer to cherry pick any event at any given moment.

We definitely have to get good at the backend, but logging objects should provide a significant advantage.

On Tue, Jan 13, 2015 at 10:05 AM, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

Log4J does do Event object logging by default. I see it may be relevant to roll it into log4s also.  I remember Toothpick probably did that

On Tue, Jan 13, 2015 at 11:30 AM, Hern��n Morales Durand <hernan.morales@gmail.com> wrote:

First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j

I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :(

So if Object logging is implementing #asLog and #logClass methods maybe I should add them so Log4s can log "Object" :). But seriously, such comparison is not fair. Let's compare real logging features: priorities, levels, appenders, output destinations, hierarchical logging, formatting layout, etc. Many of them are implemented in Log4s.

Cheers,

Hern��n

2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:

> On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
>
> hi all,
>
> Googling a bit for a logging framework in Pharo, I found sl4j, which sounds  familiar to me.
> http://ss3.gemstone.com/ss/Log4s.html/Wiki
>
> I suppose the API is the same as the java package, as claimed by the project page.
> I wonder if anybody is using it , or has tried it and have an advice on that package ?
> (I  saw there was no test and no comments ... :( )
>
> I think it could be great for Pharo to have a standard package like that, a logging facility is mandatory for most -if not all- applications
>
> Any advice or pointers ?

Object logging instead of String logging is the way to go. SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past discussions.

> TIA
> --
> Regards,
>
> Alain
>
>

--

www.tudorgirba.com

"Every thing has its own flow"