Martin Ritchie wrote:
2009/7/8 Rafael Schloming <[email protected]>:
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
Hi,
The developer writting the log shouldn't need to understand how
everything is wired together.
On construction the Channel/Connection objects would retrieve a logger:
_statusLogger = StatusLoggerFactory.createLogger(this); //Where this
is a Channel object
Then when it is used it would be very similar to log4j. The only
difference being that we provide details of what is requesting the
logging.
if (_statusLogger.isInfoEnabled(connectonLogActor))
{
_statusLogger.info(connectonLogActor, LogMessages.QUEUE_DECLARE(queue));
}
A few random questions...
- how would this work if you're outside the Channel or Connection
object and don't have access to _statusLogger?
- how exactly does isInfoEnabled(...) make an intelligent choice on
what to log, e.g. wouldn't it need access to the queue in order to know
if logging is enabled for that queue?
- where does connectionLogActor come from?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
