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:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Ceki Gülcü -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
