logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leathers, Burton" <Burton.Leath...@Cognos.COM>
Subject RE: Making object rendering more extensible
Date Wed, 13 Feb 2002 15:21:35 GMT
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 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.

Burton



-----Original Message-----
From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
Sent: Tuesday, February 12, 2002 11:00 PM
To: Log4J Developers List
Cc: Lance Larsen
Subject: Re: Making object rendering more extensible


Your example illustrates the problem well but, IMHO, the proposed 
solution falls far short of what's needed.

It is common to let admins control the format of log files. If you 
consider HTTP servers rather than ftp servers they probably all have 
configurable formatting of log entries.  It is really not sufficient to 
be able to have different ObjectRenderers for different layouts. For a 
really useful solution it is necessary to have

   1) the ability to configure how objects are rendered
   2) have the mechanism fit in well with PatternLayout

To use your example, I'd like to be able to configure a category to log 
FTPCommandInfo objects using a *mixture* of FTPCommandInfo specific 
conversion characters and built-in PatternLayout characters. I would 
also like to have the existing set of format *modifiers* apply to any 
FTPCommandInfo specific conversion characters.

If I understand what you're correctly, you're suggesting that instead of 
that, we have multiple ObjectRenderers that format FTPCommandInfo 
objects differently.  IMHO, that goes totally against the strength of 
log4j, which is configurability.  If someone decides they want to format 
  FTPCommandInfo objects slightly differently they actually have to go 
and write a new class.  Wouldn't it be much more useful to be able to 
assign new conversion characters to those different fields of the 
FTPCommandInfo and have them blend in with PatternLayout like other 
conversion characters?

Anders


Lance Larsen wrote:

> Note, it would be helpful if you could copy me on the response to this. I
am
> following the dev list, but  am not subscribed to it at the moment, so it
is
> difficult to respond on the thread unless I get the e-mail directly.
> 
> I can't speak for Anders, but it does sound like he is interested in
> addressing the same issue I am trying to face currently. Hopefully he will
> express more of his thoughts later, but here is my shot at answering your
> questions:
> 
> 
>>Ceki says:
>>I still don't see the *practical* use of having the renderer depend on
>>the layout or appender. Would it be possible for you to describe a
>>practical case where such functionality would be useful.
>>
> 
> I wouldn't necessarily say the 'ObjectRenderer(s)' should depend on
> 'Layout(s)' or 'Appender(s)', but rather that there can exist multiple
> 'ObjectRenderer' sets (refered to as 'ObjectRendererBundle' from here on
> out), and that the log4j configuration include the ability to specify per
> 'Layout' an 'ObjectRendererBundle' that the 'Layout' will use. The
> 'ObjectRendererBundle' is independant of the 'Layout' and can be
associated
> with multiple 'Layout(s)' in the same sense that a 'Layout' is independant
> of an 'Appender' and can be associated with multiple 'Appender(s)'.
> 
> In the architecture, it appears that 'Layout(s)' are responsible for
> formatting log data that is sent to the 'Appender', but
'ObjectRenderer(s)'
> are also responsible for part of this formatting process. I am running a
few
> cases where I have multiple 'Layout(s)' and each of these 'Layout(s)' need
> to coordinate with the 'ObjectRenderer(s)' to format text correctly. In
> other words, the result each of these 'Layout(s)' need from the
> 'ObjectRender' is different for the same object, and there does not seem
to
> be a way to address this in log4j at present.
> 
> I will try to give a practical example here. You will have to let me know
if
> this helps, or if there are things I need to clarify. Lets say we have an
> FTP server written in java. We include the capability to log FTP commands
> that the FTP server receives. The FTP command info is stored in an
instance
> of the following class:
> 
> public class FTPCommandInfo
> {
>    public String m_fromIP; // FTP client IP
>    public String m_toIP; // FTP server IP
>    public int    m_port; // FTP port
> 
>    public String m_username; // User for connection
>    public String m_password; // Password for connection
> 
>    public String m_command; // The FTP command that was issued
>    public String m_filePath; // The file
>    public String m_result; // The FTP server result
>    ...
> }
> 
> In some FTP server class we have some code like the following:
> 
> Logger log = ...;
> ...
> FTPCommandInfo ftpInfo = ...;
> // The FTP command info gets populated in ftpInfo
> ...
> log.info(ftpInfo);
> ...
> 
> The logging occurs for each FTP command that get called. In configuring
> log4j, we decide we want a few different 'Appender(s)' to listen to this
> 'Logger', with the ability to run them all at the same time. We would like
> the 'Layout' associated with a first 'Appender' to return result to be in
a
> comma separated list of all the info stored in the 'FTPCommandInfo'
object:
> <FTP client IP>,<FTP Server IP>,<FTP port> ... <FTP Password>
... <FTP
> result>\r\n
> 
> The 'Layout' for the second 'Appender' should return results in an XML
> format such as the following:
> <FTPCommand client_ip="<FTP client IP>" server_ip="<FTP server IP>" ...
> result="<FTP result>"/>
> 
> The 'Layout' for the third 'Appender' should return a comma separated list
> similar to the first 'Layout'. But in this case we do not want to include
> the 'm_password' value in the log file because the log is made public and
we
> do not want to expose passwords. So the format might be exactly like the
> first case, but without the passwords included.
> 
> It is the job of the 'Layout' to format the text. The 'Layout(s)'
supposedly
> are fairly generic and delegate rendering of object data to the
> 'ObjectRenderer(s)'. This is very handy since the 'Layout' does not have
to
> understand each object that comes in. Making an 'ObjectRenderer' to hand
bac
> k a correct 'String' to the 'Layout' in any one of these cases is fairly
> trivial. It is fairly trivial to make an 'ObjectRenderer' that returns ftp
> info in a comma separated list, or one that returns the ftp info as a set
of
> xml attributes, or even one that excludes certian info the loggable object
> contains that should not be displayed. However these does not seem to be a
> way for these 'ObjectRenderer(s)' to coexist in log4j at the same time and
> associated with the respective 'Layout(s)'.
> 
> A workaround is to ignore 'ObjectRenderer(s)' and add the
> 'ObjectRender(ing)' capabilities to the 'Layout' directly but this is not
> ideal since it supervents a part of the architecture and does not allow
for
> an extensible way to render new objects. It would really be much better to
> be able to use the 'ObjectRenderer' architecture, but there is only one
> unchangable 'ObjectRenderer' set so I have to deal with a workaround.
> 
> I think it is justifiable that you may want multiple log files for
different
> purposes (we run into that fairly often), and it is quite possible that
each
> of the log files may need to render the object data in different formats.
> The example above is just one case. The best way I can think of to address
> this is to allow 'ObjectRendererBundle(s)' that allow you to render object
> differently in different 'Appender(s)' (or more correctly in different
> 'Layout(s)'). In the case that you only use a default
'ObjectRendererBundle'
> the architecture reduces to the current one. I expect that this change
would
> have minor impact on the API overall, but would allow more flexibility as
> necessary.
> 
> Is this a practical enough example? It is similar to a problem I am
> currently trying to address and I hope my explaination did it justice. I
am
> feeling the limitations of the current 'ObjectRenderer' configuration
> options. I need to have a way to render the same object in multiple ways
> within the same program. I believe that the changes I have suggested would
> help make log4j fundamentally for extensible. It is not a huge leap from
> where things are at right now and seems to be a logical extension.
> 
> Log4j really is an excellent product. I hope that you will consider the
> changes I have suggested because I think it would help make log4j more
> extensible to meet a broader set of needs in a clean and clear fashion.
> Please let me know if there is anything I can clarify, or that does not
seem
> entirely sound in the discussion above. Thanks again for an excellent
> product.
> 
> -Lance Larsen
> 
> 
>>This might be another case where Anders is a few steps ahead of me. It
>>has happened in the past... so I am all ears.
>>
> 
>>TIA, Ceki
>>
> 
>>ps: Would it be sufficient if Appender and layouts accepted configuration
>>directives for elements unknown at compile time? For example, appenders
>>are known to contain a layout element and there is code to handle layout
>>directives within an appender. The idea is to support unknown element
>>types... such as object renderers.
>>
> 
> ----- Original Message -----
> From: Lance Larsen
> To: log4j-dev@jakarta.apache.org
> Sent: Thursday, February 07, 2002 11:54 AM
> Subject: Making object rendering more extensible
> 
> 
> I have looked through the dev list to see if this has come up, but I
haven't
> seen anything so far. I have been using log4j on a few projects, and like
> the configurability and extensibility it provides - very nice - thankyou
for
> the excellent tool.
> 
> However, there seems to be one part of the architecture where I have run
> into limitations, and would like to submit a feature request. Log4j
provides
> a mechanism to register 'ObjectRenderer(s)' in the configuration. This is
> very handy since it allows you to log various types of objects that log4j
> would not natively understand by simply creating a new 'ObjectRenderer'
> class and including this in the log4j configuration (no other changes).
This
> part is very nice. The problem I have run into is cases where I would like
> the set of 'ObjectRenderer(s)' to be different for various 'Layout(s)'
used
> at the same time. There does not appear to be a way to do this.
> 
> The current assumption seems to be that there is one application global
> fundamental 'String' mapping for each loggable object type. There seem to
be
> many cases where you may want to object to be rendered differently in
> different contexts. Log4j gives you this flexibility in the relationship
of
> 'Appender(s)' to 'Layout(s)', but for some reason did not extend this to
the
> relationship between 'Layout(s)' and 'ObjectRenderer(s)'.
> 
> One case where having different object renderers is useful is in a case
> where there are several things you can pull out of an object. One
'Appender'
> (or more correctly 'Formatter') may log part of the info and another
> 'Appender' may log different info from the same object. In another case,
two
> 'Layout(s)' may need the same info, but the string format may need to be
> different for each. I do not see a clean way to currently handle either of
> these cases.
> 
> My suggestion would be to add a new concept of 'ObjectRendererBundle(s)'
> which includes a set of 'ObjectRenderer(s)' that a 'Layout' will use. In
the
> configuration, the 'Layout' can be assigned an 'ObjectRendererBundle' in a
> similar way that an 'Appender' is assigned a 'Layout'. The 'Layout' class
> could include a couple of new methods something like
> 'setObjectRendererBundle' and 'getObjectRendererBundle' to access the set
of
> object renders for the 'Layout'. There would probably be a default
> 'ObjectRendererBundle' that was global as in the current case, but the
> 'ObjectRenderer' model would be more extensible.
> 
> Are there any other thoughts or somments on this? Does this seem like a
> reasonable approach? Is this something that you are interested in
including
> into 'log4j'?
> 
> -Lance Larsen
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:log4j-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:log4j-dev-help@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.

--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message