Hi Scott, I will be getting these changes (or similar supporting changes) into cvs. I'll see what I can do tonight or tomorrow night.
thanks! -Mark > -----Original Message----- > From: Scott Deboy [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 23, 2003 9:41 AM > To: Log4J Developers List > Subject: RE: LoggingEvent and XML transport protocol > > > I've finished the integration of my UI with the receiver > framework and I had to change LoggingEvent and LocationInfo > by adding constructors that accepted all the fields.. > > public LoggingEvent(String fqnOfCategoryClass, Category > logger, long timeStamp, Priority priority, String threadName, > Object message, String ndc, Hashtable mdc, Throwable > throwable, String className, String methodName, String > fileName, String lineNumber, Hashtable properties) { > > and > > public LocationInfo(String fileName, String className, String > methodName, String lineNumber) { > > There were a few other issues but they are related to the new > chainsawappender. > > > -----Original Message----- > From: Oliver Burn [mailto:[EMAIL PROTECTED] > Sent: Sun 3/23/2003 12:58 AM > To: [EMAIL PROTECTED] > Cc: > Subject: RE: LoggingEvent and XML transport protocol > > I like the sound of this approach as well. > > > Paul, > > > >> I'd normally advocate an interface approach here, I think > >> that is a major > >> structural change, and dangerous unless we specifically > >> designed to do it as > >> part of a major release, and not part of a lot of other > >> general changes that > >> are going on now. > >> > >> I'd advocate leaving the LoggingEvent class as is, bar adding > >> a protected > >> no-arg constructor, and defining protected final setter > >> methods that modify > >> the internal data elements. This gives different classes > >> that may want to > >> produce a LoggingEvent instance the ability to instantiate > their own > >> LoggingEvent sub-class, and utilise the protected final > >> setter methods, but > >> allow every other class that is purely a consumer to view the > >> LoggingEvent > >> as it currently is with no changes (a immutable object, > >> actually since it > >> has setters, probably a 'read-almost-always' object). I > >> _think_ that is as > >> close to binary and backward compatabile as you would get..? > > > > Interesting approach. We should consider it. > > > > -Mark > > > > > --------------------------------------------------------------------- > > 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]
