logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: LoggingEvent and XML transport protocol
Date Thu, 20 Mar 2003 18:31:43 GMT
At 10:08 AM 3/20/2003 -0800, Mark Womack wrote:
> > 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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Mime
View raw message