Why use github now that we have our own git repo? Gary
<div>-------- Original message --------</div><div>From: Ralph Goers <[email protected]> </div><div>Date:08/30/2014 00:23 (GMT-05:00) </div><div>To: Log4J Developers List <[email protected]> </div><div>Subject: Re: Playing nice with JDBC </div><div> </div>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
