Hi Gary!
I'll certainly give it a go. Btw, I've seen the Message interface ant the log.info with the Message parameter. Is't creating a new Message instance way too expensive? I'm kind of a performance slut and I've speeded up OpenWebBeans to be 3x as fast as Spring (and way faster than guice and Weld too). I especially learned to be really careful to avoid unnecessary temp object creations. LieGrue, strub --- On Tue, 6/21/11, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > From: Gary Gregory <ggreg...@seagullsoftware.com> > Subject: Re: log4j-2.0 questions > To: "Log4J Developers List" <log4j-dev@logging.apache.org> > Cc: "Log4J Developers List" <log4j-dev@logging.apache.org> > Date: Tuesday, June 21, 2011, 12:04 AM > > > On Jun 20, 2011, at 17:33, "ralph.goers @dslextreme.com" > <ralph.go...@dslextreme.com<mailto:ralph.go...@dslextreme.com>> > wrote: > > Hey Mark, thanks for participating in this! See my > comments inline below. > > On Mon, Jun 20, 2011 at 12:22 PM, Mark Struberg > <<mailto:strub...@yahoo.de>strub...@yahoo.de<mailto:strub...@yahoo.de>> > wrote: > Hi folks! > > My name is Mark and I had a few discussions about log4j 2.0 > with Ralph lately. It is about the question whether > log4j-2.0 would be a candidate for all the internal logging > of Apache Maven or not. > > I've checked out the sources they build fine. I'm not a > logging expert, but more a casual programmer, so please > excuse any dumb questions: > > First, there are no dumb questions and even if there were > these aren't. Second, as you can tell from where it is > located this has not yet been accepted as the official Log4j > 2.0. It is something I've been working on for over a year in > the hopes that it will become that, but that won't happen > without the kinds of scrutiny and questions you are asking > so they are most welcome. > > > How close is the code to something close to a beta? > > > 1.) is the logging implementation pluggable? > > How do you mean "pluggable"? Legacy Log4j is > "pluggable" in that you can specify your own classes of > things in the configuration. That said, the new > implementation no longer requires class names being declared > in the configuration and instead uses annotations to locate > pluggable elements. It is also designed so that the > API is distinctly separate from the implementation, much > like SLF4J. As you should be able to tell I've also made the > implementation callable using any of the Log4j 1.2, SLF4J, > or Commons Logging APIs. > > > 2.) is there an optional support for > ThreadContextClassLoader scenarios? > This is often a problem for logging in libraries which are > on a shared classpath. Imagine 2 webapps, both using > OpenWebBeans as CDI container. One webapp sets the > org.apache.webbeans loglevel to debug, the other wone to > WARN ... > > As it currently stands, no, but I have always intended to > introduce something to support that. > > When I wrote the Log4j 2 API it took a stab at creating an > abstraction to bind the API to an implementation. It was > only when I built the core that I added the plugin support. > Looking at how it is done it now occurs to me that the > plugin support really should move to the API and be used to > bind to the implementation. This would provide the > flexibility needed to accomplish this. > > How much work us that? > > Gary > > > > 3.) I've seen that the API now uses ellipsis parameters. > Wouldn't it be better to re-position the Throwable parameter > before the String parameter? Otherwise that might interfere > with the Object... parameter, isn't? > > One advantage of leaving the throwable at the end is that > it makes it more compatible with existing APIs. For example, > if you look at the Commons Logging adapter you will notice > that Log4JLog.java has no methods in it as they all come > from the Log4J 2 API. Moving the params would also make it > more difficult to match the SLF4J API since it does not do > what you are suggesting. > > There are two cases here. In the first the method signature > includes a Throwable. In that case it is unambiguous and is > handled properly. In the second case, Joern Huxhorn provided > the ParameterizedMessage class that detects that the last > Object in the array is a Throwable and handles it. > However, there is an oddity that in some cases the Throwable > appears in the ParameterizedMessage isn't propagated to the > LogEvent correctly. I'll create a test for that and fix it. > > I'd certainly consider a change to this if you would like > to wade in and give it a shot. :-) > > > > 4.) How much work is left to do before you could perform a > first 'teaser release'? For starting with using log4j we > would at least need anything which got released. > > I've been hacking away on it pretty much on my own trying > to add a little bit more of what is missing from Log4J 1.2 > every day.I have most of the Filters, Layouts and Appenders > although the DBAppender is still not there. It also doesn't > have JMX support yet. At work we are also using Flume > so I'm thinking I will want to add an Appender to work with > it. > > That said, this is the first real discussion of Log4J 2.0 > in a year or so. > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
