Will a .contains(...) check be a performance bottleneck? In a list, this usually means a scan of the entire list...
Paul > -----Original Message----- > From: Scott Deboy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 10 June 2003 6:12 AM > To: Log4J Developers List > Subject: RE: LoggingEvent - equals, hashcode? > > > I'm not going to implement the map/loggingevent tablemodel, > although it's probably worth adding equals and hashcode to > allow set-based collections of reconstructed LoggingEvents. > > I can prevent dupes with the tablemodel I'm using now, as > long as they provide the ID property. > > I'll just do a 'contains' check in the add method and not add > it if it's already in the model..and of course I'll document > that the tablemodel doesn't allow duplicates.. > > -----Original Message----- > From: Scott Deboy > Sent: Monday, June 09, 2003 10:36 AM > To: Log4J Developers List > Subject: RE: LoggingEvent - equals, hashcode? > > > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >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:[EMAIL PROTECTED] > > >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:[EMAIL PROTECTED] > > >> 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: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >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: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Ceki For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
