logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Playing nice with JDBC
Date Sat, 30 Aug 2014 04:24:42 GMT
I like the new module approach only because it lets us review it in isolation and perhaps more
easily determine what to do with it.

Ralph

On Aug 29, 2014, at 9:20 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> 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 <garydgregory@gmail.com> 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 <garydgregory@gmail.com> wrote:
> On Fri, Aug 29, 2014 at 9:55 PM, Ralph Goers <ralph.goers@dslextreme.com> 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 <garydgregory@gmail.com> 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 <boards@gmail.com> 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 <garydgregory@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org 
>> 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 <boards@gmail.com>
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> 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: garydgregory@gmail.com | ggregory@apache.org 
> 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: garydgregory@gmail.com | ggregory@apache.org 
> 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: garydgregory@gmail.com | ggregory@apache.org 
> 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


Mime
View raw message