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]>
