You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Struberg <st...@yahoo.de> on 2011/06/20 21:22:33 UTC
log4j-2.0 questions
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:
1.) is the logging implementation pluggable?
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 ...
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?
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.
txs and LieGrue,
strub
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j-2.0 questions
Posted by Mark Struberg <st...@yahoo.de>.
Oki, I understand.
txs 4 the explanation!
LieGrue,
strub
--- On Tue, 6/21/11, Joern Huxhorn <jh...@googlemail.com> wrote:
> From: Joern Huxhorn <jh...@googlemail.com>
> Subject: Re: log4j-2.0 questions
> To: "Log4J Developers List" <lo...@logging.apache.org>
> Date: Tuesday, June 21, 2011, 9:39 AM
>
> On 20.06.2011, at 23:33, ralph.goers @dslextreme.com
> wrote:
>
> > Hey Mark, thanks for parThere 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.
>
> Theres an issue in ParameterizedMessage? Please let me know
> of anything you find out!
> I tested that class quite thoroughly...
>
> The fact, that ("{}", someThrowable) does not propagate the
> Throwable to the event, is by design. It is only used as the
> Throwable of the message if it is not "used up" by a
> placeholder.
> Otherwise, it wouldn't be possible to simply use
> throwable.toString() as a parameter to the message without
> also creating a pretty big Throwable including stacktrace,
> cause, etc.
>
> Cheers,
> Joern.
> ---------------------------------------------------------------------
> 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
Re: log4j-2.0 questions
Posted by Joern Huxhorn <jh...@googlemail.com>.
On 20.06.2011, at 23:33, ralph.goers @dslextreme.com wrote:
> Hey Mark, thanks for parThere 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.
Theres an issue in ParameterizedMessage? Please let me know of anything you find out!
I tested that class quite thoroughly...
The fact, that ("{}", someThrowable) does not propagate the Throwable to the event, is by design. It is only used as the Throwable of the message if it is not "used up" by a placeholder.
Otherwise, it wouldn't be possible to simply use throwable.toString() as a parameter to the message without also creating a pretty big Throwable including stacktrace, cause, etc.
Cheers,
Joern.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j-2.0 questions
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 20, 2011, at 5:04 PM, Gary Gregory wrote:
>
>
> On Jun 20, 2011, at 17:33, "ralph.goers @dslextreme.com" <ra...@dslextreme.com>> wrote:
>
>
> 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?
This shouldn't be much work at all. I'll probably do it in the next few days. The only trick is the context selection criteria and making sure the LoggerContext and configuration are properly freed when the webapp shuts down. Logback uses JNDI lookups (see http://logback.qos.ch/manual/loggingSeparation.html#ContextJNDISelector) as well as a Servlet Context Listener. I'll probably do somethnig similar, although I'd prefer to do it with annotations.
Ralph
Re: log4j-2.0 questions
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 29, 2011, at 3:11 PM, Mark Struberg wrote:
> Hi Ralph!
>
> Txs for clarifying. I thought the user needs to provide that message object.
>
> Regarding temp object creation: in HotSpot it is now much better than it used to be, but it's still an overhead.
>
> Btw, regarding Message objects and i18n logs.
> I had this discussion a while back and I still don't get it why it should be useful to internationalize logs!
I completely agree. Unfortunately, in order to provide the compatibility API for Log4J 1.x I had to provide some sort of support for it.
>
> Imo no message in any error log or whatever logfile else needs to be internationalized. It is really a pain if you only get a dumb german error message into your log but all you could find easily on the internet is english. A Hungarian or Thai local user is doomed anyway...
>
> This is completely different for messages which gets presented to some users, but _not_ for messages which only a technician will see!
Actually, the main reason I am building this is that we use SLF4J/Logback for Audit logging. The deficiencies in Logback's architecture are what motivated me to do this. Our audit logs will be viewable by our customers. But even if they were to be internationalized I would do it in the UI, not when the logs are written.
>
> So please revise this approach, it does nothing else than slowing down the logging itself and fu**n up the log for the poor guy/lady which is looking for a solution on the internet ;)
I don't think the approach needs to be revised. The localization support is handled via the LocalizedMessage class. As I said, that is there primarily to provide compatibility with Log4J 1.2. Perhaps I should move that class to the Log4J 1.2 API project.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j-2.0 questions
Posted by Mark Struberg <st...@yahoo.de>.
Hi Ralph!
Txs for clarifying. I thought the user needs to provide that message object.
Regarding temp object creation: in HotSpot it is now much better than it used to be, but it's still an overhead.
Btw, regarding Message objects and i18n logs.
I had this discussion a while back and I still don't get it why it should be useful to internationalize logs!
Imo no message in any error log or whatever logfile else needs to be internationalized. It is really a pain if you only get a dumb german error message into your log but all you could find easily on the internet is english. A Hungarian or Thai local user is doomed anyway...
This is completely different for messages which gets presented to some users, but _not_ for messages which only a technician will see!
So please revise this approach, it does nothing else than slowing down the logging itself and fu**n up the log for the poor guy/lady which is looking for a solution on the internet ;)
LieGrue,
strub
--- On Tue, 6/21/11, Ralph Goers <ra...@dslextreme.com> wrote:
> From: Ralph Goers <ra...@dslextreme.com>
> Subject: Re: log4j-2.0 questions
> To: "Log4J Developers List" <lo...@logging.apache.org>
> Date: Tuesday, June 21, 2011, 6:43 AM
>
> On Jun 20, 2011, at 11:06 PM, Mark Struberg wrote:
>
> > 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?
>
> Expensive compared to what? The Message object is
> only created if the first level of filtering passes. Once
> you get into creating a LogEvent and then dealing with
> Layouts, and whatever I/O appenders are going to do I doubt
> it matters much. If the Message objects didn't exist most of
> the logic in them would have to go somewhere else and they
> would actually be more expensive since you would end up with
> Layouts that have to deal with multiple kinds of
> objects. Furthermore, without Messages logging events
> with more complex objects such as Structured Data becomes
> extremely difficult. I attempted to do that in Logback with
> the EventData object but the result is very unsatisfying as
> the EventData has to be converted to XML format so that it
> can be passed through Logback and then converted back into
> an EventData object in the Layout and Appender. That mess is
> what led me to the Message interface (with the help of Joern
> Huxhorn).
>
> > 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.
>
> My understanding of Java 6 is that this is way less of an
> issue than it used to be.
>
> 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
Re: log4j-2.0 questions
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 20, 2011, at 11:06 PM, Mark Struberg wrote:
> 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?
Expensive compared to what? The Message object is only created if the first level of filtering passes. Once you get into creating a LogEvent and then dealing with Layouts, and whatever I/O appenders are going to do I doubt it matters much. If the Message objects didn't exist most of the logic in them would have to go somewhere else and they would actually be more expensive since you would end up with Layouts that have to deal with multiple kinds of objects. Furthermore, without Messages logging events with more complex objects such as Structured Data becomes extremely difficult. I attempted to do that in Logback with the EventData object but the result is very unsatisfying as the EventData has to be converted to XML format so that it can be passed through Logback and then converted back into an EventData object in the Layout and Appender. That mess is what led me to the Message interface (with the help of Joern Huxhorn).
> 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.
My understanding of Java 6 is that this is way less of an issue than it used to be.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j-2.0 questions
Posted by Mark Struberg <st...@yahoo.de>.
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 <GG...@seagullsoftware.com> wrote:
> From: Gary Gregory <GG...@seagullsoftware.com>
> Subject: Re: log4j-2.0 questions
> To: "Log4J Developers List" <lo...@logging.apache.org>
> Cc: "Log4J Developers List" <lo...@logging.apache.org>
> Date: Tuesday, June 21, 2011, 12:04 AM
>
>
> On Jun 20, 2011, at 17:33, "ralph.goers @dslextreme.com"
> <ra...@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
> <<m...@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
Re: log4j-2.0 questions
Posted by Gary Gregory <GG...@seagullsoftware.com>.
On Jun 20, 2011, at 17:33, "ralph.goers @dslextreme.com" <ra...@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 <<m...@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
Re: log4j-2.0 questions
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
Hey Mark, thanks for participating in this! See my comments inline below.
On Mon, Jun 20, 2011 at 12:22 PM, Mark Struberg <st...@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.
>
> 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.
>
> 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