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
