> >But, do we want to give the outside world the ability to 
> arbitrarily change
> >the data members of a logging event?  Right now, you create 
> the logging
> >event and its members are essentially "fixed".  Allowing the 
> values to be
> >set at creation time (either via a constructor that takes valeus for
> >NDC,MDC,property,etc or via different implementations of a 
> common interface)
> >seems preferrable to giving wholesale access to changing the 
> values at any
> >time, and I thought that was a desirable feature of logging 
> event (ie once
> >created, it could not be fundamentally changed).
> 
> That is correct. Going the interface way is not a bad idea at 
> all. Another 
> possibility is to keep LoggingEvent as a class, add 
> setters/getters, plus a 
> special method called lock() or makeReadonly(). Once lock() 
> is called the 
> setters would not longer respond or alternatively throw 
> SecurityExceptions 
> when called.

I may be missing the point of the discussion, but..

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..?


cheers,

Paul Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to