On 20.03.2009, at 15:28, Ceki Gulcu wrote:
Hello Joern,
As much as I don't enjoy declining your suggestions,
;)
given that LoggingEvent is the central class in logback-classic, I don't see how supporting j.u.l. justifies fattening the LoggingEvent class.
Well, it would be an optional 8 bytes....
In particular, why do you say that threadId is worthy additional data? From logback's persperctive (setting jul aside for a moment) what new informaiton is in threadId that is not in threadName?
In an ideal world it would be of no use whatsoever because every Thread would have a meaningful, unique and constant name. In the real world, where at least third-parties might create several threads with the exact same name or could even change the thread name, I see a value in that info. Obviously not in *just* that info as in jul but as an additional hint of what is actually going on. Otherwise you might think (I would) that all messages are created by the exact same Thread while they are actually generated by several threads with the same name. Joern.
Joern Huxhorn wrote:
Hi Ceki and sorry for the late reply on this one... On 04.03.2009, at 18:38, Ceki Gulcu wrote:
Hello Joern,
The javadocs for getId state:
public long getId()
Returns the identifier of this Thread. The thread ID is a positive long number generated when this thread was created. The thread ID is unique and remains unchanged during its lifetime. When a thread is terminated, this thread ID may be reused.
Thus, the id is not guaranteed to be unique either... That's true but it is unique, at least, at the time of the LoggingEvent creation which would be sufficient I think. The reason I'm asking this is that I'm looking into import of various logging events into Lilith and I had to realize that jul is sending *only* the thread id, *not* the name of the thread - which is pretty pointless if you ask me. Therefore I saw the requirement to support more than just the name to be able to import jul events lossless concerning the contained info. I created a ThreadInfo class that contains the following: threadName threadId threadGroupName threadGroupId (this is System.identityHashCode(threadGroup) since there is no such thing as a ThreadGroup id) All of those are optional. In case of current logback-classic only threadName is filled in, in case of jul only threadId. At the moment, my LogbackLoggingAdapter is filling in the additional info itself which means that you'll get all of the above if you use my appender. I think it's worthy additional data.
-- 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