There's a bson dependency in log4j-nosql as well (from mongo). On 26 May 2016 at 11:46, Gary Gregory <garydgreg...@gmail.com> wrote:
> 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 >> > -- Matt Sicker <boa...@gmail.com>