> 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. 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). I did take it a bit further with the suggestion that there could be a common interface for LoggingEvent that has different implementations. 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. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
