2009/7/8 Rafael Schloming <rafa...@redhat.com>:
> 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));
}
Resulting in :
2009-06-29 13:35:10,1234 +0100 MESSAGE [ con:1(gu...@127.0.0.1/)/ch:2
] QM-1002 : Queue Declared : 'queue'
The text in [] is provided by the _status logger based on the actor
and is of the format [ <Actor>/<logger> ]. So here we have a localhost
connection by guest creating a queue on Channel 2.
So if the same queue was declared via the management console you might
see something like:
2009-06-29 13:35:10,1234 +0100 MESSAGE [ jmx:1(ad...@127.0.0.1/) ]
QM-1002 : Queue Declared : 'queue'
The jmx connection is identified as the originator of the queue
declare. In this case the logger does not need to augment the actor
details as is down with the Channel Logger above.
You can identify that the two operations are equivellant by their log
id here 'QM-1002', but you can see where and who instigated the
operation, something that is missing just now.
The main implementation goal is to minimise the time required for
logging and minimise the temporary objects created in the logging
process.
Hope that is clearer :)
Martin
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
