I don't like this approach.
I think we should wait to refactor this component until we'll switch to
java 5 as the required jvm so we can introduce a Logger interface with
the mixin's methods we need.
If you want to avoid complex evaluation for debugging you will have to
use the isXXXXEnabled anyway, so I don't see so much advantages is this
approach. You only optimize the concatenation and not the other calls
that could be needed by the log statements.
Stefano
robert burrell donkin wrote:
perhaps one plan would be to factor out logging calls into a
JamesLogEnabled class. the idea would be abstract all logging calls
into a superclass. this would perform a null check on the logger and
the isXXXEnabled. it would also provide pre-parameterized calls:
info(Object one)
info(Object one, Object two)
...
(yes, i know that this is close to ceki's forth generation bridging
logging interfaces and i make no claim of originality)
this would mean all string building code is in one place whilst also
increasing the readibility of the code.
yes, i know that there probably are concerns about including mixin's
as part of inheritance hierarchies but this is done already in james
and the alternative is bytecode engineering.
since IMAP uses an experimental logging scheme and i'm having to add
lots of logging to understand my email issues, maybe i'll add
something along those lines to my local version...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
