The only part about this that bothers me is that it makes the DataSource attached to the JDBC appender “special”. What about other DataSources? What about other classes that want to use a PrintWriter or PrintStream? 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.
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 ExtendedLoggers. > > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > 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 > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
