You can push branches. Branches work far better in git, so we can use them
a lot more. But pushing your own fork onto GitHub somewhere is another way
to get a more graphical view of what's different.


On 30 August 2014 12:06, Gary Gregory <[email protected]> wrote:

> OK, so a new module it is for now.
>
> Gary
>
>
> On Sat, Aug 30, 2014 at 12:24 AM, Ralph Goers <[email protected]>
> wrote:
>
>> 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 <[email protected]> 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 <[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
>>
>>
>>
>
>
> --
> 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]>

Reply via email to