Hi Ceki, Thorbjoern and Maarten, I'd like to encourage all of you to take a look at my LoggingEvent implementation at http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data , more specific the classes in http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data/logging/sr... The LoggingEvent is just a dumb data container with the only logic being a (lazy) call to MessageFormatter if the formatted message is actually needed. Beside that, all the classes are simply Java Beans with both getters and setters for everything. They also have a default c'tor. This means they can be persisted using java.beans.XMLEncoder/ XMLDecoder which would probably be the best candidates to support future updates because they handle such a situation gracefully. I've done some benchmarks which you can check out at http://apps.sourceforge.net/trac/lilith/ticket/28 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. Concerning immutability, I seriously fail to see any advantage of immutable data objects because the immutability can be circumvented anyway. Because of that it should be sufficient to define the hierarchy like this: interface ImmutableLoggingEvent { // only getters } interface MutableLoggingEvent extends ImmutableLoggingEvent { // only setters } class LoggingEvent implements MutableLoggingEvent { } and simply using the LoggingEvent as an ImmutableLoggingEvent as needed to document that certain classes, like appenders, aren't supposed to change the event. Granted, it would obviously still be possible to cast it to MutableLoggingEvent but it's also possible, on the other hand, to change private variables using reflection, so immutability is only a contract/illusion, anyway. I also still think that the LoggingEvent should not know about the logic behind the transformation from the Object[] arguments to the String[] arguments. Therefore I'd suggest to define void setArgumentArray(String[]) instead of void setArgumentArray(Object[]) (see http://jira.qos.ch/browse/LBCLASSIC-45 ) My LoggingEvent is using a ThrowableInfo similar to the class I suggested in http://jira.qos.ch/browse/LBCLASSIC-46 It's keeping the throwable hierarchy intact because a ThrowableInfo can have another ThrowableInfo as it's cause and so on... On a side note, the MessageFormatter contained in the same package implements my suggestions from the following slf4j "bugs": http://bugzilla.slf4j.org/show_bug.cgi?id=31 http://bugzilla.slf4j.org/show_bug.cgi?id=70 http://bugzilla.slf4j.org/show_bug.cgi?id=112 (there's just one usability glitch left which I'll fix in the near future but I'll leave it up to you to spot it ;)) I'd have absolutely no problem donating all that code back to both Logback and SLF4J, although some work would be required to backport it to jdk < 1.5... Oh, I almost forgot: My LoggingEvent does also contain support for an enhanced version of the NDC - but that functionality could simply be removed if undesired. What do all of you think? Joern. On 23.02.2009, at 18:58, Ceki Gulcu wrote:
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Hello all,
I would like to split/redesign the LoggingEvent object as follows: Hi. Could you elaborate on what you want to achieve? Makes it easier to evaluate your suggestion.
One important goal is to better support interoperability between logback versions. For example, in a client/server situation, when a client is using a different version of logback than the server. Here the client is the application generating LoggingEvent instances and the server is the application receiving serialized LoggingEvent instances via the network.
A second goal is to simplify the code in LoggingEvent. If LoggingEvent instances do not have to worry about serialization, then LoggingEvent can be simplified. LoggingEventMemento needs to worry about serialization, replacing LoggingEvent in client/server communication.
Another goal of this RFC is to identify uses of LoggingEvent so that logback can cater for those use cases, possibly via new object types.
It is not clear how LoggingEventMemento would actually ensure version compatibility, especially if LoggingEventMemento fields change in time. However, as LoggingEventMemento is only a data carrying tpye, it is likely to be much smaller in (code) size.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev