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/src/main/java/de/huxhorn/lilith/data/logging
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
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
