I think we can support BSON through Jackson. That would be interesting for 2.7.
Gary On May 26, 2016 6:47 AM, "Remko Popma" <remko.po...@gmail.com> wrote: > Kirk, > > Logging in binary format has been on my todo list for a while. > We did some preliminary analysis here: > https://issues.apache.org/jira/browse/LOG4J2-1305 > Your thoughts on this effort would be much appreciated. > > Remko > > On Thursday, May 26, 2016 at 5:32:27 PM UTC+9, Kirk Pepperdine wrote: >> >> Hi, >> >> Sorry this might read a bit provocative then intended. In general I >> applaud this effort and to be fair I’ve not only picked on Log4J in the >> past. IM(not so)HO, all logger and in particular JDK logging has been a >> disaster from both an API and underlying design POV. >> >> >> On May 26, 2016, at 9:41 AM, Mikael Ståldal <mikael....@magine.com> >> wrote: >> >> http://12factor.net/logs >> >> >> I actually see little wrong with this approach. It is rare that I run >> into an application that isn’t bottlenecked on logging when you combine all >> of the problem that come from logging. The JDK logger, because of it’s >> design, is responsible for class loader leaks. The API’s in all loggers >> encourage programming styles that are responsible for excessive memory >> pressure. Though I gripe about the obscene amount of work that logging >> frameworks engage in, generally it’s not the logging framework that is >> directly responsible for memory pressure, it’s what has to be done to use >> the logging framework that is the source of the problem. >> >> To tackle this I’ve been pushing simple solutions such that the one >> pushed here. Loggers should only push messages directly to a sync point and >> do no more than that. Anything that injects extra work into a threads >> workflow should be discarded. This includes activities such as decorating >> and/or reformatting running through appenders.. and so on.... Even record >> ordering (if it needs to be done) should happen else where. Additionally, I >> give the ( very unpopular) advice) that logging should use binary/machine >> readable formats (a practice adopted by Twitter and a number of other >> players) in favor of eye readable formats (which tend to be neither human >> nor machine readable). In messaging, of which logging is a form of >> messaging, information density counts and human readable formats tend to be >> exceptionally information sparse. When you combine these techniques you can >> get tremendous (orders of magnitude) improvements in performance. As much >> as I’m a fan of the disruptor, I fail to see how building on top of it >> solves any of the above mentioned problems. >> >> Kind regards, >> Kirk >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >