logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: log4j-2.0 questions
Date Tue, 21 Jun 2011 06:06:52 GMT
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.


--- On Tue, 6/21/11, Gary Gregory <GGregory@seagullsoftware.com> wrote:

> From: Gary Gregory <GGregory@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.goers@dslextreme.com<mailto:ralph.goers@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:struberg@yahoo.de>struberg@yahoo.de<mailto:struberg@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message