We can also discuss _where_ this should live. While the deps are only on the API module, it would be nice to have it there but it might feel odd so I would be OK to have in the core. Having a new module (as now in the patch) is another way to do, but as you may know, the fewer modules the better AFAIAC. The new module approach has the benefit that it does not drag in Core if you do not need it but I am not sure how often that would be.
Gary On Sat, Aug 30, 2014 at 12:16 AM, Gary Gregory <[email protected]> wrote: > I've taken another scan at the code and here is a proposal. > > - Bring in code to support PrintWriter and PrintStream. Both are needed to > support legacy systems. > - Discuss and clean up. > - Save the rest of the code in a patch, so we can keep on playing with it > and discuss it. > > That will bring down the size of the package down to 4 classes I think. > > Gary > > > On Fri, Aug 29, 2014 at 11: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 >>>>> <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 >> > > > > -- > 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
