On May 21, 2010, at 11:15 PM, Ralph Goers wrote: >> >>> 1. I first created an API that had the features I was looking for. That is >>> in log4j2-api. While it supports logging a String or an Object it really >>> uses a Message interface which is valuable as it allows users to log >>> self-describing objects in a convenient manner. >> >> My thinking was the message interface would end up so minimal that might as >> well just use Object. > > I don't think so. For example, take a look at StructuredDataMessage and > LocalizedMessage. Those allow you to do some interesting things. The idea is > that it is easy for users to extend without having to muck with the > internals. Ceki handled this by creating logback-classis, logback-access and > logback-audit. That seemed to me to be a very heavyweight approach to > accomplish this.
Definitely will look at, just wanted to let you know my unchallenged inclination. I'm willing to be convinced. A little off track, there was a long ago thread that wandered between log4j and commons logging about localization of logging that came to mind. Took me a while to find it, but the threads of interest are: http://article.gmane.org/gmane.comp.jakarta.commons.devel/59103/match=arnold+enterprise http://www.mail-archive.com/log4j-u...@logging.apache.org/msg00479.html > >> >> >>> 2. I don't like the way Logback binds to the implementation. I used a >>> technique I had used in a previous logging framework and used a file to >>> define the implementation class. In theory, the API could be modified to >>> support multiple logging implementation simultaneously, although I have no >>> plans to implement that. >> >> Not something that I've thought about. > > Probably not. It just occurred to me that it is possible as I was > implementing it but decided it wasn't an itch I needed to scratch at the > moment. > >> >> >>> 3. Logback suffers from a serious architectural problem that is rooted in >>> Log4j. The configured loggers are mixed with the loggers returned from the >>> Logger factory. This makes it impossible to reconfigure atomically. With >>> Logback the reset method is called on the context which essentially causes >>> the system to be in an undefined state until the new configuration is >>> completed (log records that should be logged are lost). To solve this I >>> used a design that I again borrowed from my previous framework. The >>> configuration is separated and on a reconfiguration the new configuration >>> will be created and then all the loggers will be updated to use it. While >>> there will be a period where some loggers are using the old configuration >>> and some the new there is never a point where loggers aren't configured at >>> all. >> >> I think that is along the line that I was thinking, basically there is an >> immutable configuration state object that is swapped out as an atomic >> operation with notification to allocated loggers. > > Exactly. > >> >> >>> 4. Similar to Logback I added support for Markers and global filters. In >>> addition, filters on Loggers are also supported. Unlike Logback, there is >>> only a single Filter interface used for global filters, logger filters and >>> appender filters. >> >> I've never had a clear description of the use cases behind Markers. As far >> as I can gather, it is a specialized case of a user supplied context. At >> the core, I think it would fit into a general user-supplied context object. >> MDC and NDC would be part of the thread-supplied context and there'd be a >> global context and a call-site context. In the core, I'd expect the context >> parameters to just be Object and let the layout level cast to specific known >> interfaces as needed. During the synchronous extraction phase, an immutable >> package would be assembled for from log request parameters and the contexts >> based on the needs of the layout's formatting phase. > > I think I'd need to see code to get what you are driving at. In the code I > checked in it does have the MDC & NDC and does have a global context, > although I haven't added variables to it yet. It also has the configuration > which can also have variables, but probably for a different purpose. I don't > know what you mean by "call-site context". I was meaning the context that is only valid for the duration of the call, essentially the info that you'd get from new Throwable().getStackTrace(). > > The value of Markers is that they are fast and easy to filter on. I use them > for Entry and Exit so that you can easily filter them out (admittedly this > can also be done via the TRACE level) as well as catching and throwing. In > addition, I also use a Marker to identify audit events. Anything with that > Marker will always be logged. > Still seems like a specialized user context object to me. Don't know if there is a user-supplied context object outside of it. Will need to take a look. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
