[logback-dev] Small LoggingEvent suggestion

[Joern Huxhorn]

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 at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev