On Fri, Aug 29, 2014 at 9:55 PM, Ralph Goers <[email protected]> wrote:
> Based on what I saw before I disagree. If we can get something relatively > simple I might change my mind, but what we previously had was way too > complicated to have in core. > My use case is to integrate with JDBC logging, so that's only dealing with a PrintWriter and none of the other streaming classes. The JDBC use of a PrintStream for logging is deprecated, so I would not deal with it at first. So can we start with that? There is a lot of complicate code in core, so I am not sure if that is a good argument (in my mind). Gary > Ralph > > On Aug 29, 2014, at 3:33 PM, Gary Gregory <[email protected]> wrote: > > Matt, > > Thank you for looking into this as well. I'm debugging some tests... > > I think this streaming code should be in core, not in a new module. > > Gary > > > On Fri, Aug 29, 2014 at 2:16 PM, Matt Sicker <[email protected]> wrote: > >> I still have a patch that has the work Bruce and I did with that. We have >> a log4j-streams module for that. It's also in a branch somewhere, but I've >> had to convert it into a patch due to divergence from the trunk. I'll make >> a new git branch or something later tonight. >> >> >> On 29 August 2014 12:36, Gary Gregory <[email protected]> wrote: >> >>> Hi All, >>> >>> In am now developing some fancy JDBC proprietary do-hicky at work. >>> >>> In JDBC, you log to a java.io.PrintWriter like this: >>> >>> // for all drivers >>> DriverManager.setLogWriter(printWriter); >>> >>> // for a specific driver (if that driver support it). >>> dataSource.setLogWriter(printWriter); >>> >>> I want logging to go to Log4j 2. Granted, I've got no control with >>> levels but at least I could give it a (single) level (see below) and, as >>> usual, if I want the target to be the console or a file and do rollovers >>> and such. >>> >>> I could see wrapping a PW and then giving that to JDBC and Log4j somehow: >>> >>> log4jPw = new Log4jPrintWriter(logger, Level.DEBUG); >>> >>> ... someLog4jObject.addEventSource(log4jPw); >>> >>> DriverManager.setLogWriter(log4jPw); >>> // or >>> dataSource.setLogWriter(log4jPw); >>> >>> The PW would buffer until it gets a println() or the buffer reaches some >>> size limit, then turns its buffer into log event. >>> >>> Also, JDBC 4.1 in Java 7 has some integration with JUL with >>> javax.sql.CommonDataSource.getParentLogger() but each driver has to support >>> that. >>> >>> My requirements look like a perfect match with log4j2-547 and it looks >>> like Bruce put a lot of work in there. >>> >>> So I am going to experiment to bring that code base in. >>> >>> Thoughts? >>> >>> Gary >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
