Now that we are on git I would suggest creating a clone on github to do this and then letting us look at it when it is done.
Ralph On Aug 29, 2014, at 8:45 PM, Gary Gregory <[email protected]> wrote: > 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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
