Martin Ritchie wrote:
Regarding the detailed design notes, I'm struggling a bit to understand the
purpose of the various interfaces you describe. Based on the high level
overview, I would have imagined something simpler, e.g. Channel.log(...),
and Connection.log(...).
I was thinking that there would be concrete implementations of the
interface that would look much as you point out:
ChannelMessageStatusLogger , ConnectionMessageStatusLogger , etc.
Keeping the logging separate from the Channel and Connection
implementation gives the freedom to more easily change the way the
loggers would work. The inital pass will simply wrap log4j but I have
seen issues with log4j blocking on a full file system so there is
potentailly a reason to replace log4j. Having the calls to log4j in a
single place would make it much easier to replace.
You also want to minimise the amount of processing and state a log
statement requires. So ensuring any object creation is guarded with an
isEnabled and giving an object that has cached the formated log string
means we can do less processing on every log. This will be important
when we start looking to log on the message delivery path where we
really need to minimise any impact of the logging.
Hope that answers your questions.
If not let me know :)
Using facades and delegates makes sense on the implementation side, but
it doesn't seem like a good idea to need to understand how they're all
wired together in order to actually log a message. I might be getting
the wrong end of the stick though. Maybe you could post a more detailed
example of the API portion as you see it being used to perform logging?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
