Am 13.01.2015 um 19:41 schrieb Hern��n Morales Durand <hernan.morales@gmail.com>:

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

> On 13 Jan 2015, at 18:27, Hern��n Morales Durand <hernan.morales@gmail.com> wrote:
>
>
>
> 2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
>
> > On 13 Jan 2015, at 07:00, 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 :(
>
> Maybe we should do away with Events as objects, Methods as objects, Exceptions as objects, Announcements as objects, Ring, MC, Commands as objects, Windows, Menus, ... - well, this whole objects everywhere thing is silly, let's use strings instead ;-)
>
>
> Sarcasm is never the answer. Let's focus on logging, and specifically the case with remote image where you don't have access to "local log objects". I suppose there are other (specially web) developers with the same requirement.

The analogy was to make a point, but you don't seem to see it, too bad. It is technically easy to export log objects out of an image.

Instead of analogies, I would love to read about how your Log system proposals works with headless images. Because to me it is really easy to write a grep command (I don't have to *explore* logs).

��

It can work the way you want it to. The main difference might be that you don't produce strings inside your code when logging. You create objects with contextual information and you emit them. A convert/outputter/appender can then convert the objects into a desired format before it leaves the image. Or you can keep the objects in the image. The only difference might be that we keep objects as long as possible and postpone to convert it to less rich format as long as possible. But you don't need to produce special objects, you can just log strings as the most basic thing as well (because string is an object).��

So it is up to you if you write those objects as strings to a file, if you generate a hierarchical format like json and transmit it via tcp or you keep the objects in the image having a http handler where you can specify a query for the objects and format to be returned. We just want it to be small and extensible. Using objects in the core is the best way to do it. Because then it is up to you if you want to log string messages or a whole stack.

Norbert

> We'll keep on trying to explain and to explore the possibilities.
>
> Log objects are much more powerful, less expensive than you think, and backwards compatible with textual output.
>
>
> If I have to use a bayesian model with markov chains, which could take up to 1 million of samplings only to begin stabilization, and I want to log them... do you expect to have every entry as a Log object... right? That would be less expensive in terms of memory and speed than flushing to a text file?

That would only be true if you kept them all in memory. That is an orthogonal point.

So you didn't answered my questions. Do I have to create 1 million of log objects and that is less expensive than flushing them as they occur into a file?
What's the point of creating objects if I don't need them?

��

<sorry-for-the-sarcasm>A String instance is an object too, composing/formatting a log message is a computation too, similar to serialising an object in some format.</sorry-for-the-sarcasm>

I see. In the end we (still) read Strings, whatever conceptualization is above them.
��

> Logging is deceptively simple, managing megabytes of log files is a PITA. Structure, classification, intelligence, behaviour are the answers.
>
> BTW, it is not that you are not allowed to log some simple things to the Transcript, it is that it does not really scale, conceptually.
>
>
> In my system I am not logging to the Transcript (which obviously does not scale).

I was using the Transcript as an example of a text based logging facility. I meant that it doesn't scale conceptually, it becomes one big mess of dozens of log files that helps very little.

Look, you don't have to use any form of Object Logging if you fail to see the point, there is nothing wrong with logging to a file. I was just trying to explain.

The point is isn't just me. I haven't seen any intensive computation software which creates log objects for self-exploration. And if you find one, I could cite 100 of them which does "String logging", and they just work, and people using it is not stupid, they know they have limitations, it happens that they prioritize other requirements.
��

We have dozens of servers producing many, many log files, most of them produced by log4j, writing more than 1Gb a day. 90% of that is a waste, but it is never enough. And it is a big mess. Even our Java developers say so. And what are they looking at ? Right, storing JSON log objects in searchable databases. (LogStash, ElasticSearch, blabla, ..).

It is weird to read sometimes how Java developers have it so wrong, and sometimes they are visionary souls which drive us into the future.

Hern��n

��