logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Making object rendering more extensible
Date Thu, 07 Feb 2002 23:41:15 GMT
Lance, Anders,

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.

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.


At 14:54 07.02.2002 -0500, Anders Kristensen wrote:
>Lance,
>
>You're absolutely right that this is a crippling limitation. I argued this 
>point with some vigor a long time ago but with zero luck. What I would 
>have liked to see is:
>
>  1) configurable ObjectRendererd, and
>  2) the ability to have per-category ObjectRenderers
>
>This would allow us to log a Foo object differently in different context, 
>the way you ask for.
>
>Anders
>
>
>Lance Larsen wrote:
>
>>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>
>

--
Ceki Gülcü



--
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