> As I follow this thread of discussion I find myself concerned that
> there is a serious issue here which needs to be correctly identified.
>
> So far as I am concerned, log4 is a really great tool for controlling
> the generation and handling the downstream distribution of log records.
> It is not, and should not, be focused on formatting. There are lots of
> really good tools which take that as their primary task. If people are
> concerned with providing high quality, content and context sensitive
> formatting of log4 output, then let them emit the records in XML and
> use something like XSLT to handle the formatting.
I agree. I think it is a great tool for "handling downstream distribution of
log records". However this does not make the ability to do filtering and
rendering of the content an unimportant or unuseful part of th archtiecture.
Often you need the data to be interpreted in some format just so the
"downstream" repository know how to handle it. In many cases, different
repositories may understand different formats. If you log things other than
'String(s)' it is very handy to have a good architecture for turning this
data into a form that is readable or parseable by the log repository (or
tools that work with the log repository). Developers seem to be making good
use of this functionality ('Layout(s)' and 'ObjectRenderer(s)'). Of course
you can ignore this part of the architecture if it does not suit your needs.
I have found them to be very handy. I am just suggesting that this part of
the architecture should be a flexible as possible to allow extension where
necessary. The changes I suggested are not large and do allow more
flexibility in how you handle loggable objects.
> I like log4 too much to want to see it pulled away from its core function.
> Ages ago I took as a fundamental tenet of object design that an object
> should do just one thing but do it exceedingly well. log4 has one thing
> it does exceedingly well. With interoperability tools like XML, it is
> practical to "delegate" highly attractive but non-core tasks like
> formatting to other equally good and equally single minded tools.
The problem is that right now log4j is not extensible enough to "delegate"
the responsibility of formating. Making the suggested changes do not change
the core competency of log4j and should have little impact on how people are
currently able to use log4j. The changes I suggested merely make a natural
extension to the current design that allow more flexibility to the
'ObjectRendering' capabilities.
I have not yet digested Anders comments. He is suggesting a different
strategy to address this problem, and I can't comment on the virtues yet.
However, it is clear that he sees some value in extending the
ObjectRendering capabilities also, so I expect there are others that would
also like to use log4j for similar purposes.
-Lance
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
