http://docs.oracle.com/javase/8/docs/api/javax/sql/CommonDataSource.html#setLogWriter-java.io.PrintWriter-
> Messages printed to a data source- specific log writer are not printed to the log writer associated with the java.sql.DriverManager class. When a DataSource object is created the log writer is initially null; in other words, the default is for logging to be disabled. On 3 September 2014 10:37, Gary Gregory <[email protected]> wrote: > My understanding is that setting a PW on a DriverManager is for all of > JDBC and any driver. Setting a PW on a DataSource is just for that one data > source instance. > > Each driver may implement logging in any way of course, so there is no > guarantee. > > Gary > > > On Wed, Sep 3, 2014 at 9:08 AM, Matt Sicker <[email protected]> wrote: > >> One thing to note is that CommonDataSource takes a PrintWriter as well >> which says it's separate from the DriverManager log. If you look up a >> DataSource via JNDI and set a log writer, will that take effect everywhere? >> Or do you need to rebind it? >> >> >> On 3 September 2014 00:54, Gary Gregory <[email protected]> wrote: >> >>> On Wed, Sep 3, 2014 at 1:46 AM, Ralph Goers <[email protected]> >>> wrote: >>> >>>> The only part about this that bothers me is that it makes the >>>> DataSource attached to the JDBC appender “special”. >>>> >>> >>> JDBC is special because it is part of the JRE. What other JRE classes >>> configure their logging with a PrintWriter or PrintStream? Those would be >>> special too and deserve built-in support. >>> >>> >>>> What about other DataSources? >>>> >>> >>> If a DS is not used in Log4j, then I claim it is not our business from >>> the config's POV. You can use our iostream classes in code. >>> >>> >>>> What about other classes that want to use a PrintWriter or PrintStream? >>>> >>>> >>> >>> As above. >>> >>> It would seem like you would want to register those as well and then be >>>> able to reference them. But if you do that then you are reinventing Spring >>>> - or worse, competing with it. >>>> >>> >>> Not generically IMO, see above. Right, we do not want to create some >>> config language a la Spring. >>> >>> Right now we create DS's in two ways: >>> >>> - JNDI >>> - Reflection to invoke a factory method. >>> >>> For both we can add some extra config attributes to specify logger name >>> and level (and maybe a marker). >>> >>> Then there is the special case of setting up logging JDBC-wide in the >>> DriverManager. >>> >>> Gary >>> >>> >>>> >>>> Ralph >>>> >>>> On Sep 2, 2014, at 8:58 PM, Gary Gregory <[email protected]> >>>> wrote: >>>> >>>> Since JDBC is in the JRE and a common API I thought it might deserve >>>> special treatment. >>>> >>>> We already support configuring a data source, for example: >>>> >>>> <Appenders> >>>> <Console name="STDOUT"> >>>> <PatternLayout pattern="%C{1.} %m %level MDC%X%n"/> >>>> </Console> >>>> <Jdbc name="databaseAppender" tableName="dsLogEntry" >>>> ignoreExceptions="false"> >>>> <DataSource >>>> jndiName="java:/comp/env/jdbc/TestDataSourceAppender" /> >>>> <Column name="eventDate" isEventTimestamp="true" /> >>>> <Column name="literalColumn" literal="'Literal Value of Data >>>> Source'" /> >>>> <Column name="level" pattern="%level" /> >>>> <Column name="logger" pattern="%logger" /> >>>> <Column name="message" pattern="%message" isUnicode="false" /> >>>> <Column name="exception" pattern="%ex{full}" isClob="true" /> >>>> </Jdbc> >>>> </Appenders> >>>> >>>> could become: >>>> >>>> <DataSource jndiName="java:/comp/env/jdbc/TestDataSourceAppender" >>>> logger="SOME_LOGGER_NAME" level="DEBUG" /> >>>> >>>> where OFF is the default level and default logger name is the data >>>> source class name. >>>> >>>> The would be something like: >>>> >>>> dataSource.setLogWriter(new LoggerPrintWriter((ExtendedLogger) >>>> LogManager.getLogger(_some_name_), _some_level_)); >>>> >>>> Calling java.sql.DriverManager.setLogWriter() could be triggered by a >>>> top level Jdbc element. >>>> >>>> What other JRE classes take a PrintWriter or PrintStream for >>>> configuring logging? >>>> >>>> >>>> Gary >>>> >>>> >>>> On Tue, Sep 2, 2014 at 11:39 PM, Matt Sicker <[email protected]> wrote: >>>> >>>>> Wouldn't people normally use something like Spring, Guice, or OSGi to >>>>> do that? I mean, we could add support for that, but it would certainly be >>>>> an interesting plugin to create. We're not recreating xbean here, right? >>>>> >>>>> >>>>> On 2 September 2014 22:00, Gary Gregory <[email protected]> >>>>> wrote: >>>>> >>>>>> Yes, the config creates the loggers, but something has to tell Log4j >>>>>> to call DriverManager.setLogWriter(). >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> On Tue, Sep 2, 2014 at 10:55 PM, Matt Sicker <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Wouldn't the XML just configure the Logger itself? The streams are >>>>>>> all adapters. >>>>>>> >>>>>>> >>>>>>> On 2 September 2014 21:42, Gary Gregory <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>> >>>> >>>> >>> >>> >>> -- >>> 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]>
