[logback-dev] RFC: LoggingEvent redesign

[Joern Huxhorn]

Thorbjoern Ravn Andersen wrote:
> Joern Huxhorn skrev:
>>
>> XML encoding *is* significantly slower, especially because gzipping
>> isn't just an option but a must if you take a look at the increase of
>> size in case of XML.
> The sole reason for compressing is because the network connection is
> too slow.  Does that hold here?
>
> It would be nice if the server allowed for both compressed and
> uncompressed transparently.  Also gzipping is rather slowish :)
Well, I'm using the benchmarked classes as the native file format of Lilith.
My appenders (both the xml and serialization version) all have
compression as an option. Ultimately, it all depends on the
infrastructure and the actual logging events.
We use logging in our live environment (our web-developers are receiving
errors if something is wrong in one of the templates of our CMS) and
single events can get quite big so in our case it increases performance.
>> Concerning immutability, I seriously fail to see any advantage of
>> immutable data objects because the immutability can be circumvented
>> anyway.
> In my world immutability deals with that you cannot CHANGE a current
> object, but you can create a new object based on an old one.  It gives
> a different mindset.
Ok, I *do* understand what immutability is *supposed* to be about but
reality is quite different. In the two languages that I know best - Java
and C++ - constness and immutability can be circumvented easily.

Consequently, I consider immutable objects (i.e. objects that only
provide getters in Java or, as is the case with the current
LoggingEvent, throw an exception in the setter if a value has previously
been set) just as a documentation that they should/must not be changed.
If this results in significantly reduced functionality (like e.g. the
inability to use XMLEncoder) then the price is too high
 for the mere illusion of some kind of security (who is protected
against what, anyway?).

The interface suggestion provides essentially the same. While instances
aren't really immutable, the interface documents that they should not be
changed.

To give a concrete example:
the append method of Appender would have an ImmutableLoggingEvent as
it's argument. Any appender would still have the ability to cast  it to
a MutableLoggingEvent but it would be clear from the perspective of the
method signature that it should not change the event while processing it.

Using reflection, it is absolutely possible to change anything, even
static final constants.

I'm not very fond of the memento suggestion because it would create
twice the amount of objects as the current implementation and I guess
that this will have some garbage collection impact.

Joern.