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
