[logback-dev] RFC: LoggingEvent redesign

[Thorbjoern Ravn Andersen]

Joern Huxhorn skrev:
>
>> 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.
>   
I am not doubting that you have real life experience with this, but I am 
curious if you have benchmarked to see how large the gain is by 
compressing the large events you describe?

(I guess you are on a 100 Mbit network?)
>>
> 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.
>
>   
If you can access an object through reflection you can do anything with 
it, including making a private member public (IIRC) and vice versa.    
The idea as I understand it is not to "protect" anything but to state 
that events are not changable after the fact.  Which makes sense to me.  
A good example of a framework on immutable objects is the JODA framework 
for handling dates and times, which is recommended reading for anyone 
who has suffered with dealing with dates and times across timezones in 
the Calendar framework (which was not designed by Sun).


> 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?).
>
>   
Strings are immutable.  Have that been a major hinderance in your 
programming work so far?

What would make XMLEncoder break?

> 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.
>   
Java programs generally create a lot of short lived objects and the 
garbage collectors know very well how to deal with them.  I suggest we 
measure to see if there is a difference :)  You probably have some very 
large datasets?

-- 
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"