On Tue, Sep 2, 2014 at 10:37 PM, Matt Sicker <[email protected]> wrote:
> DriverManager.setLogWriter(LoggerStreams.forLogger(DriverManager.class).atLevel(Level.DEBUG)); > or something like that > > Then you'd just configure the "java.sql.DriverManager" logger. > Yes, but what in the XML config triggers this code? Gary > > > On 2 September 2014 21:30, Gary Gregory <[email protected]> wrote: > >> Let's _also_ look at the JDBC use cases from a configuration POV. >> >> What should my XML config look like to say: >> >> (1) Redirect all JDBC logging to DEBUG (or any level). >> At the low level, that means: >> >> java.sql.DriverManager. >> setLogWriter(new LoggerPrintWriter((*ExtendedLogger*) >> LogManager.getLogger(), Level.DEBUG)); >> >> (2) Redirect JDBC logging for a given JDBC appender to DEBUG (or any >> level): >> java.sql.CommonDataSource.setLogWriter(new LoggerPrintWriter(( >> *ExtendedLogger*) LogManager.getLogger(), Level.DEBUG)); >> >> ? >> >> Gary >> >> >> On Tue, Sep 2, 2014 at 9:36 PM, Matt Sicker <[email protected]> wrote: >> >>> We could make a LogManager-style class that's only used for streams. The >>> LoggerStreams class looks like a good candidate, but due to the lack of >>> javadocs anywhere, I'm not sure what anything does anymore! Well, anything >>> that isn't an override of all the java.io methods. >>> >>> Is it required that all Log4j providers use ExtendedLogger instead of >>> just Logger? Because if it isn't, then that limits this a bit. If it is >>> required, then that makes things easier. I would like a way to do something >>> like: >>> >>> PrintWriter pw = >>> LoggerStreams.forLogger("com.foo.Bar").atLevel(Level.INFO).marked(FOO).buffered(4096).build(); >>> >>> (Names aren't final at all). A sort of fluent builder would be much >>> nicer than the dozens of constructors everywhere. I'm sure you know what I >>> think about methods and constructors that take more than a few parameters. >>> ;) >>> >>> >>> On 2 September 2014 19:46, Gary Gregory <[email protected]> wrote: >>> >>>> Matt and all: >>>> >>>> Please review *log4j-streams *in master. >>>> >>>> The current nasty is this the required type cast to *ExtendedLogger*: >>>> >>>> java.sql.DriverManager.setLogWriter(new LoggerPrintWriter(( >>>> *ExtendedLogger*) LogManager.getLogger(), Level.DEBUG)); >>>> >>>> Internally, *LogManager.getLogger()* uses an *ExtendedLogger* but >>>> upcasts it to a plain *Logger*, for no good technical reason (see >>>> below). >>>> >>>> Specifically: >>>> >>>> public static Logger getLogger(final String name) { >>>> final String actualName = name != null ? name : getClassName(2); >>>> return factory.getContext(LogManager.class.getName(), null, >>>> null, false).getLogger(actualName); >>>> } >>>> >>>> Where *getLogger() *is: >>>> >>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(String) >>>> >>>> The only reason I've heard on the ML to upcast from *ExtendedLogger* >>>> to *Logger* is to hide the extra method from users. This now seems >>>> like jumping through hoops for not much effect. >>>> >>>> We cannot downcast the public API without breaking BC. >>>> >>>> I see the following options: >>>> >>>> - Do nothing and force call sites to downcast (good enough today). >>>> - Add *ExtendedLogger* version of methods to *LogManager*. >>>> - Create a parallel class to *LogManager *called *ExtendedLogManger *that >>>> only deals *ExtendedLogger*s >>>> >>>> *.* >>>> Thoughts? >>>> >>>> Gary >>>> >>>> >>>> >>>> >>>> On Tue, Sep 2, 2014 at 8:11 PM, Gary Gregory <[email protected]> >>>> wrote: >>>> >>>>> I'm almost done, I'll commit, please review... >>>>> >>>>> Gary >>>>> >>>>> >>>>> On Tue, Sep 2, 2014 at 7:53 PM, Matt Sicker <[email protected]> wrote: >>>>> >>>>>> Yeah I think I can take care of that tonight. >>>>>> >>>>>> >>>>>> On 2 September 2014 14:41, Gary Gregory <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Matt, >>>>>>> >>>>>>> Do you have time for that today? >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> >>>>>>> -------- Original message -------- >>>>>>> From: Matt Sicker >>>>>>> Date:09/02/2014 14:20 (GMT-05:00) >>>>>>> To: Log4J Developers List >>>>>>> Subject: Re: log4j-streams and ExtendedLoggers >>>>>>> >>>>>>> Yeah I think that'd be a good idea. >>>>>>> >>>>>>> >>>>>>> On 2 September 2014 09:49, Gary Gregory <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> So... should retype all of the methods that cast to ExtendedLogger >>>>>>>> and in turn their call sites? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Sep 2, 2014 at 10:22 AM, Matt Sicker <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This was written before all that was done. I had to rename it from >>>>>>>>> LoggerProvider to ExtendedLogger even! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2 September 2014 09:21, Gary Gregory <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Some of the streams API take a org.apache.logging.log4j.Logger >>>>>>>>>> and cast it to an org.apache.logging.log4j.spi.ExtendedLogger. >>>>>>>>>> >>>>>>>>>> Why not just type to an ExtendedLoggers? >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <[email protected]> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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
