> To say the least, I am surprised by the conclusions because I > am unable to > follow the reasoning. > > Why can't LoggingEvent be modified to accept setters and getters for > various fields? What backward compatibility issues are there > if you add > methods but do not remove anything? Kinda lost here...
I was making the assumption that since the setters were not already part of the LoggingEvent interface, that there was a reason they weren't there. It seemed to me that having "read-only" access to the LoggingEvent members was a desired trait (except for the new properties that obviously need to allow setting). If this assumption is incorrect, then I'll maybe I should add the setter methods tonight.
It is a correct assumption.
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.
Changing LoggingEvent to an interface *seems* to involve many changes in the code whereas the lock() method may be less intrusive. On the other hand, the interface way looks architecturally more sound.
I did take it a bit further with the suggestion that there could be a common interface for LoggingEvent that has different implementations.
You mean you wrote code or given it more thought.
If I'm going down the wrong, confusing road here, I'll try to clarify some more. I was pretty tired when I wrote my email last night, and I apologize for that.
No apology required. I just did not see it coming, that's all.
-Mark
--
Ceki
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
