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
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.
In particular, why do you say that threadId is worthy additional data?
From logback's p
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
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
Hi all,
I'd like to suggest to include thread id (in addition to the name) in
LoggingEvent.
I'd use a Long as the data type instead of long so it's possible to
distinguish if it was initialized or not.
The name alone isn't guaranteed to be unique so the id wouldn't hurt, imho.
Joern.
___
