logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <Scott.De...@VirtualDesign.Net>
Subject RE: LoggingEvent - equals, hashcode?
Date Mon, 09 Jun 2003 17:35:53 GMT
IDs are already a supported part of the tablemodel - they are uniquely generated if not provided
as a property of the event.

If a 'log4jid' property is provided, it is set as the event's ID in the tablemodel (for example,
when receiving JDK1.4 logging events, the event's SEQUENCE is set as the 'log4jid' property
and reused in the model as the event's ID).

I could use a map in the tablemodel and key off of the ID but I'd have to think through it
for a bit - the current buffer is a list - either ArrayList or CyclicBufferList...wondering
how sorting would be affected, etc.


-----Original Message-----
From: Ceki Gülcü [mailto:ceki@qos.ch] 
Sent: Monday, June 09, 2003 10:29 AM
To: Log4J Developers List
Subject: RE: LoggingEvent - equals, hashcode?



Very interesting. Actually, one solution could be to number events or tag 
them with an ID (for retrieval from a database.)

A similar technique could be used to replicate 'tail -f' behavior. The ID 
would be linked to the position of the event within the file. Assuming, the 
position did not change the id would also remain stable.

At 10:01 AM 6/9/2003 -0700, you wrote:
>In Chainsaw V2 I was thinking about making the tablemodel support 
>LoggingEvents directly and make it set-based, so receivers that are 
>usually used in an offline mode (database receiver, xml file receiver) 
>could support a timed refresh.  Of course this doesn't make sense if 
>other appenders are plugged in as well, but it would allow the Chainsaw 
>tablemodel to ignore duplicates.
>
>For example, I'd add params to the database receiver or file import 
>that allowed a refresh flag and a rate (think tail -F or re-retrieve 
>from a database on a timer).
>
>Just an idea..doesn't make a lot of sense since these receivers are 
>generally for offline analysis of events..but I was thinking of the 
>lowest-common-denominator platform that couldn't log to anything but a 
>text file but still wanted to use the UI interactively.
>
>== doesn't fit the bill because receivers which re-create the 
>loggingevent from some other representation (xml, text -
>database/multicast/udp/xmlsocketreceivers) create new LoggingEvents 
>when they are received and parsed, so a 'refresh' of already-existing 
>events would create new events in the model..
>
>
>
>-----Original Message-----
>From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
>Sent: Monday, June 09, 2003 9:48 AM
>To: Log4J Developers List
>Subject: RE: LoggingEvent - equals, hashcode?
>
>
>
>Howdy,
>I'm not aware of a strong domain-specific reason not to implement these 
>methods.  But in the general sense, these methods can be non-trivial to 
>implement.
>
>I've almost always found it preferable to either implement Comparable 
>or Comparator specific to the comparison needs at the time.  That way 
>other people can use their own comparator as needed.
>
>So maybe the question is, why do you need these?
>
>Yoav Shapira
>Millennium ChemInformatics
>
>
> >-----Original Message-----
> >From: Mark Womack [mailto:mwomack@bevocal.com]
> >Sent: Monday, June 09, 2003 12:40 PM
> >To: 'Log4J Developers List'
> >Subject: RE: LoggingEvent - equals, hashcode?
> >
> >I can't think of good reason why they shouldn't be if you need them.
> >
> >-Mark
> >
> >> -----Original Message-----
> >> From: Scott Deboy [mailto:Scott.Deboy@VirtualDesign.Net]
> >> Sent: Friday, June 06, 2003 9:40 PM
> >> To: Log4J Developers List
> >> Subject: LoggingEvent - equals, hashcode?
> >>
> >>
> >> Anyone know of a reason why these methods aren't implemented?
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>
>
>This e-mail, including any attachments, is a confidential business 
>communication, and may contain information that is confidential, 
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied, 
>printed, disclosed or used by anyone else.  If you are not the(an) 
>intended recipient, please immediately delete this e-mail from your 
>computer system and notify the sender.  Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki  For log4j documentation consider "The complete log4j manual"
       ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Mime
View raw message