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
