You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Marius Volkhart <Ma...@volkhart.com> on 2020/12/05 22:36:01 UTC
Logging
Hello,
POI currently uses a custom facility for logging: the POILogger interface.
This serves as a level of indirection to allow consumers to plug in a
logging implementation of their own. Best as I can tell, this facility was
added nearly 10 years ago, and the logging landscape has changed a lot in
that time. I'd like to revisit this facility.
The impact of temporary objects due to logging has been of increasing focus
in the last few years. Projects like Apache Log4J have gone to great
lengths to reduce the number of temporary objects created for logging
purposes, and run garbage-free in some configurations. At this time,
POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
Object...) requires at least an Object[] allocation, even if the message
won't be logged. In many cases, string concatenation is done before calling
log(int, Object...), resulting in more allocations. The logging frameworks
like Log4J have solved this by adding overloads that take a varying number
of arguments.
Once inside of log(int, Object...), if it is determined that the message
should be logged, the common case of a single Object array is not optimized
for. Furthermore, the log forging escape regex is compiled every time.
Despite providing an indirection of it's own, POI still has a hard
dependency on Apache Commons Logging, and ships with a POILogger
implementation that defers to Commons Logging.
The performance topics could all be addressed without much difficulty. The
question I pose is, should they be? Other Apache projects exist to focus on
the problem of how to do logging well. I propose that POI uses one of the
logging frameworks directly, rather than having the POILogger abstraction.
10 years ago, logging frameworks didn't split their API and backend the way
that Log4J and SLF4J/Logback do today, so the need for an indirection was
greater.
Commons Logging is already a dependency, so it may seem a logical choice is
to use it directly. However, Commons Logging has a very limited API, which
would make POI authors write more logging code than they do now. It also
suffers from high garbage.
Instead, I propose that Log4J is the more logical choice. It's a popular
logging framework, under the Apache umbrella, and is a leader when it comes
to considering performance while providing rich logging APIs. Using the
Log4J API lets application authors decide if they want to use Logback,
Log4J Core, or some other logging backend, and gives them a lot of
flexibility in how logging is done.
Of course, removing POILogger is an API change. However, it is marked as
being @Internal, and previous discussion
<https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
unlikely to be many users of this API. This feels like a change that could
happen after the 5.0 release.
I would like to complete this work, and would also write new documentation
to explain how POI submits log events to the Log4J API.
Proposed changes:
- Remove Commons Logging dependency
- Add Log4J API dependency
- Remove POILogger API
- Remove POILogFactory API
- Modify all log sites to use Log4J API
- Write new documentation for how POI submits events
--
Cheers,
Marius Volkhart
Re: Logging
Posted by Marius Volkhart <Ma...@volkhart.com>.
+1 for b + e
+1 for logging changes not holding up 5.0.1
I'll happily do the work, including appropriate changes to the docs on the
website.
--
Cheers,
Marius Volkhart
On Mon, Jan 25, 2021 at 8:21 AM Dominik Stadler <do...@gmx.at>
wrote:
> Hi,
>
> +1 for a 5.0.1 first, there were already a few useful fixes which we could
> pack into a small bugfix release along with fixes for the "known issues" in
> 5.0.0.
>
> On the actual framework to use I don't have a preference, I seem to end up
> with at least 3 different ones in any project as soon as more than a few
> dependencies are dragged in, so trying to stick to one never really works
> anyway.
>
> Dominik.
>
> On Sat, Jan 23, 2021 at 11:11 PM PJ Fanning <fa...@yahoo.com.invalid>
> wrote:
>
> > If we change the logging to log4j2 then I think we should at least bump
> > the POI version to 5.1.0.
> >
> > I would prefer to see a 5.0.1 release before we make the logging change -
> > since we raised awareness of a known issue in the release notes.
> >
> > I would like to see POILogger removed. I dislike having to use a system
> > property to override the default POILogger implementation (NullLogger).
> >
> > In the past, I'd have preferred slf4j because it gives users more control
> > as to what logging implementation to use but slf4j doesn't seem to be as
> > actively maintained as it once was.
> >
> >
> >
> >
> >
> >
> > On Saturday 23 January 2021, 20:39:04 GMT, Andreas Beeker <
> > kiwiwings@apache.org> wrote:
> >
> >
> >
> >
> >
> > Hi Devs,
> >
> > As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I think
> > the logging topic can be discussed again.
> >
> > So do we want ...
> > a) to keep SLF4J
> > b) or replace it with Log4j 2
> > c) or any other logging api
> >
> > ... and ...
> > d) to keep the POILogger class/facade
> > e) or directly call the Logging API
> >
> > As we have now some time until 5.0.1, I would vote for b) + e). I can
> also
> > do the replacement if no-one else dares too.
> >
> > What's your stance?
> >
> > Are dependency changes like this a major (semver) version change?
> >
> > Andi
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> > For additional commands, e-mail: dev-help@poi.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> > For additional commands, e-mail: dev-help@poi.apache.org
> >
> >
>
Re: Logging
Posted by Alain FAGOT BÉAREZ <ab...@for-scala.it>.
Hi,
+1 for a 5.0.1 before the switch to Log4j, removing the POILogger from the code base
Alain FAGOT BÉAREZ
Obter o BlueMail para Android
Em 25 de jan de 2021 08:21, em 08:21, Dominik Stadler <do...@gmx.at> escreveu:
>Hi,
>
>+1 for a 5.0.1 first, there were already a few useful fixes which we
>could
>pack into a small bugfix release along with fixes for the "known
>issues" in
>5.0.0.
>
>On the actual framework to use I don't have a preference, I seem to end
>up
>with at least 3 different ones in any project as soon as more than a
>few
>dependencies are dragged in, so trying to stick to one never really
>works
>anyway.
>
>Dominik.
>
>On Sat, Jan 23, 2021 at 11:11 PM PJ Fanning
><fa...@yahoo.com.invalid>
>wrote:
>
>> If we change the logging to log4j2 then I think we should at least
>bump
>> the POI version to 5.1.0.
>>
>> I would prefer to see a 5.0.1 release before we make the logging
>change -
>> since we raised awareness of a known issue in the release notes.
>>
>> I would like to see POILogger removed. I dislike having to use a
>system
>> property to override the default POILogger implementation
>(NullLogger).
>>
>> In the past, I'd have preferred slf4j because it gives users more
>control
>> as to what logging implementation to use but slf4j doesn't seem to be
>as
>> actively maintained as it once was.
>>
>>
>>
>>
>>
>>
>> On Saturday 23 January 2021, 20:39:04 GMT, Andreas Beeker <
>> kiwiwings@apache.org> wrote:
>>
>>
>>
>>
>>
>> Hi Devs,
>>
>> As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I
>think
>> the logging topic can be discussed again.
>>
>> So do we want ...
>> a) to keep SLF4J
>> b) or replace it with Log4j 2
>> c) or any other logging api
>>
>> ... and ...
>> d) to keep the POILogger class/facade
>> e) or directly call the Logging API
>>
>> As we have now some time until 5.0.1, I would vote for b) + e). I can
>also
>> do the replacement if no-one else dares too.
>>
>> What's your stance?
>>
>> Are dependency changes like this a major (semver) version change?
>>
>> Andi
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
>> For additional commands, e-mail: dev-help@poi.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
>> For additional commands, e-mail: dev-help@poi.apache.org
>>
>>
Re: Logging
Posted by Dominik Stadler <do...@gmx.at>.
Hi,
+1 for a 5.0.1 first, there were already a few useful fixes which we could
pack into a small bugfix release along with fixes for the "known issues" in
5.0.0.
On the actual framework to use I don't have a preference, I seem to end up
with at least 3 different ones in any project as soon as more than a few
dependencies are dragged in, so trying to stick to one never really works
anyway.
Dominik.
On Sat, Jan 23, 2021 at 11:11 PM PJ Fanning <fa...@yahoo.com.invalid>
wrote:
> If we change the logging to log4j2 then I think we should at least bump
> the POI version to 5.1.0.
>
> I would prefer to see a 5.0.1 release before we make the logging change -
> since we raised awareness of a known issue in the release notes.
>
> I would like to see POILogger removed. I dislike having to use a system
> property to override the default POILogger implementation (NullLogger).
>
> In the past, I'd have preferred slf4j because it gives users more control
> as to what logging implementation to use but slf4j doesn't seem to be as
> actively maintained as it once was.
>
>
>
>
>
>
> On Saturday 23 January 2021, 20:39:04 GMT, Andreas Beeker <
> kiwiwings@apache.org> wrote:
>
>
>
>
>
> Hi Devs,
>
> As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I think
> the logging topic can be discussed again.
>
> So do we want ...
> a) to keep SLF4J
> b) or replace it with Log4j 2
> c) or any other logging api
>
> ... and ...
> d) to keep the POILogger class/facade
> e) or directly call the Logging API
>
> As we have now some time until 5.0.1, I would vote for b) + e). I can also
> do the replacement if no-one else dares too.
>
> What's your stance?
>
> Are dependency changes like this a major (semver) version change?
>
> Andi
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
Re: Logging
Posted by PJ Fanning <fa...@yahoo.com.INVALID>.
If we change the logging to log4j2 then I think we should at least bump the POI version to 5.1.0.
I would prefer to see a 5.0.1 release before we make the logging change - since we raised awareness of a known issue in the release notes.
I would like to see POILogger removed. I dislike having to use a system property to override the default POILogger implementation (NullLogger).
In the past, I'd have preferred slf4j because it gives users more control as to what logging implementation to use but slf4j doesn't seem to be as actively maintained as it once was.
On Saturday 23 January 2021, 20:39:04 GMT, Andreas Beeker <ki...@apache.org> wrote:
Hi Devs,
As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I think the logging topic can be discussed again.
So do we want ...
a) to keep SLF4J
b) or replace it with Log4j 2
c) or any other logging api
... and ...
d) to keep the POILogger class/facade
e) or directly call the Logging API
As we have now some time until 5.0.1, I would vote for b) + e). I can also do the replacement if no-one else dares too.
What's your stance?
Are dependency changes like this a major (semver) version change?
Andi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by Andreas Beeker <ki...@apache.org>.
Hi Devs,
As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I think the logging topic can be discussed again.
So do we want ...
a) to keep SLF4J
b) or replace it with Log4j 2
c) or any other logging api
... and ...
d) to keep the POILogger class/facade
e) or directly call the Logging API
As we have now some time until 5.0.1, I would vote for b) + e). I can also do the replacement if no-one else dares too.
What's your stance?
Are dependency changes like this a major (semver) version change?
Andi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by Marius Volkhart <Ma...@volkhart.com>.
While SLF4J continues to have this interface, Log4j 2 has added many new
APIs to improve on this one. Taking a single Object... requires a Object[]
allocation regardless of whether or not the message will get logged.
Additionally, every primitive needs to be boxed before being added to the
array. A look at the Javadocs for Log4j 2's Logger,
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html, reveals
that they have many overloads that take varying number of parameters to
avoid the allocation and the boxing. Furthermore, Log4j 2 has the Unbox
API, https://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html, to
avoid the autoboxing of primitives. Log4j 2 also adds a lambda-based
overload that only executes the lambda after determining that the message
will be logged. This is especially handy for situations where the
parameters being logged are non-trivial to compute.
Log4j 2 has also introduced a LogBuilder API,
https://logging.apache.org/log4j/2.x/manual/logbuilder.html. This brings
new performance wins for users who log location information and also makes
logging nearly free in the event that logging is disabled, as a no-op
LogBuilder implementation is used. On the topic of location information,
going through the POILogger abstraction makes it impractical for
application developers to get useful location information, as the location
that the logging implementations see is always POILogger.
While Log4j (the original) did combine the frontend/backend and thereby
forced a logging framework on library consumers, this is not true of Log4j
2. Log4j 2, like SLF4J/Logback, splits the frontend and backend into Log4j
2 API and Log4Jj2 Core. The Log4j 2 API can be used with Logback if an
application developer desires. The advantage to using the Log4j 2 API over
SLF4J is that we can take advantage of the API improvements that Log4j 2
has made to reduce the cost of logging code when not enabled. SLF4J has not
made these improvements. There is an FAQ answer that Log4j 2 provides that
goes into more details about SLF4J API vs Log4j 2 API
https://logging.apache.org/log4j/2.x/faq.html#api-tradeoffs
As a final note, when reviewing the POI code, there are many POILogger call
sites that do string concatenation prior to calling log(...), so there are
a number of code changes that should take place regardless. Again, I'm
happy to make the required changes, and if there's a specific timeline
you'd like them on, I can probably accommodate it.
--
Cheers,
Marius Volkhart
On Sun, Dec 13, 2020 at 2:43 PM fanningpj@apache.org <fa...@apache.org>
wrote:
> The POILogger is actually a reasonably good implementation.
>
> default void log(int level, Object... objs) {
> if (!check(level)) return;
>
>
> https://github.com/apache/poi/blob/trunk/src/java/org/apache/poi/util/POILogger.java
>
> This is basically what slf4j and log4j do too. The objs will not be
> appended into a string if the log level is not required.
>
> I would still favour modifying POILogger to use slf4j under the hood but
> this saves us having to rewrite all the logging code. If there is a better
> API than the one above, we can add extra methods to POILogger when needed
> and switch some logging to use the new methods over time.
> I would favour slf4j because users can choose which logging
> implemenatation they prefer as opposed to us mandating a specific framework
> life log4j.
>
> If noone objects, I can make the slf4j change to POILogger before the
> 5.0.0 release.
>
>
>
>
>
>
>
> On Tuesday 8 December 2020, 20:43:35 GMT, Dominik Stadler <
> dominik.stadler@gmx.at> wrote:
>
>
>
>
>
> Hi,
>
> I also see the custom logging functionality unnecessary and outdated,
> replacing it with one of the popular log-frameworks would be nice.
>
> However I see POI mostly as a tool-library which usually should only log
> very few things, mostly only warnings in some cases when it is being used
> incorrectly in some way. We then be able to enable debug logs with some
> configuration change to investigate things if necessary.
>
> Choosing the "right" logging framework is hard for me, unfortunately there
> are many choices. When building some application, I usually end up with
> many different ones dragged in via dependencies. So a solution which uses
> one of the small wrappers which can plug into most of the common frameworks
> would be nice. I think slf4j can do this as well as commons-logging. Log4J
> is the one closes to being the de-facto standard, but would be a bit harder
> to integrate into larger applications, although I don't have much
> experience with doing this, so it might work well. I would at least try it
> before making a decision.
>
> On performance/allocations: we did perform a fair amount of testing of
> Apache POI over the years and logging was never a concern as far as I know,
> probably because there are very few logging statements in the code anyway.
> So you will likely not see much of it compared to other allocations. But
> there might be cases where it becomes more prominent.
>
> Thanks... Dominik.
>
> On Sun, Dec 6, 2020 at 12:26 AM Dave Fisher <wa...@apache.org> wrote:
>
> > FYI -
> >
> > POLogger was part of the initial commit of POI to the Apache Jakarta
> > project on Jan. 31, 2002.
> >
> > https://svn.apache.org/viewvc?view=revision&revision=352063 <
> > https://svn.apache.org/viewvc?view=revision&revision=352063>
> >
> > History from svn can be found here:
> >
> >
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> > <
> >
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> > >
> >
> >
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> > <
> >
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> > >
> >
> > There were many bug fixes, etc.
> >
> > Regards,
> > Dave
> >
> > > On Dec 5, 2020, at 2:46 PM, Bill Taylor <wa...@alum.mit.edu> wrote:
> > >
> > > Good idea. I've been through the slf 4 j transition in other places.
> It
> > > is PAINFUL and nobody wants to do it, but the resulting system is a lot
> > > better.
> > >
> > > On Sat, Dec 5, 2020 at 5:36 PM Marius Volkhart <Ma...@volkhart.com>
> > wrote:
> > >
> > >> Hello,
> > >>
> > >> POI currently uses a custom facility for logging: the POILogger
> > interface.
> > >> This serves as a level of indirection to allow consumers to plug in a
> > >> logging implementation of their own. Best as I can tell, this facility
> > was
> > >> added nearly 10 years ago, and the logging landscape has changed a lot
> > in
> > >> that time. I'd like to revisit this facility.
> > >>
> > >> The impact of temporary objects due to logging has been of increasing
> > focus
> > >> in the last few years. Projects like Apache Log4J have gone to great
> > >> lengths to reduce the number of temporary objects created for logging
> > >> purposes, and run garbage-free in some configurations. At this time,
> > >> POILogger is comparatively garbage heavy. Every call to
> > POILogger.log(int,
> > >> Object...) requires at least an Object[] allocation, even if the
> message
> > >> won't be logged. In many cases, string concatenation is done before
> > calling
> > >> log(int, Object...), resulting in more allocations. The logging
> > frameworks
> > >> like Log4J have solved this by adding overloads that take a varying
> > number
> > >> of arguments.
> > >>
> > >> Once inside of log(int, Object...), if it is determined that the
> message
> > >> should be logged, the common case of a single Object array is not
> > optimized
> > >> for. Furthermore, the log forging escape regex is compiled every time.
> > >>
> > >> Despite providing an indirection of it's own, POI still has a hard
> > >> dependency on Apache Commons Logging, and ships with a POILogger
> > >> implementation that defers to Commons Logging.
> > >>
> > >> The performance topics could all be addressed without much difficulty.
> > The
> > >> question I pose is, should they be? Other Apache projects exist to
> > focus on
> > >> the problem of how to do logging well. I propose that POI uses one of
> > the
> > >> logging frameworks directly, rather than having the POILogger
> > abstraction.
> > >> 10 years ago, logging frameworks didn't split their API and backend
> the
> > way
> > >> that Log4J and SLF4J/Logback do today, so the need for an indirection
> > was
> > >> greater.
> > >>
> > >> Commons Logging is already a dependency, so it may seem a logical
> > choice is
> > >> to use it directly. However, Commons Logging has a very limited API,
> > which
> > >> would make POI authors write more logging code than they do now. It
> also
> > >> suffers from high garbage.
> > >>
> > >> Instead, I propose that Log4J is the more logical choice. It's a
> popular
> > >> logging framework, under the Apache umbrella, and is a leader when it
> > comes
> > >> to considering performance while providing rich logging APIs. Using
> the
> > >> Log4J API lets application authors decide if they want to use Logback,
> > >> Log4J Core, or some other logging backend, and gives them a lot of
> > >> flexibility in how logging is done.
> > >>
> > >> Of course, removing POILogger is an API change. However, it is marked
> as
> > >> being @Internal, and previous discussion
> > >> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there
> > are
> > >> unlikely to be many users of this API. This feels like a change that
> > could
> > >> happen after the 5.0 release.
> > >>
> > >> I would like to complete this work, and would also write new
> > documentation
> > >> to explain how POI submits log events to the Log4J API.
> > >>
> > >> Proposed changes:
> > >> - Remove Commons Logging dependency
> > >> - Add Log4J API dependency
> > >> - Remove POILogger API
> > >> - Remove POILogFactory API
> > >> - Modify all log sites to use Log4J API
> > >> - Write new documentation for how POI submits events
> > >>
> > >> --
> > >> Cheers,
> > >> Marius Volkhart
> > >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
Re: Logging
Posted by Andreas Beeker <ki...@apache.org>.
+1 for using slf4j
+0 for using the POILogger - as a temporary solution - yes, it's pragmatic, but eventually I'd like to go away from a delegate to a bridge
Andi
On 13.12.20 14:42, fanningpj@apache.org wrote:
> I would favour slf4j because users can choose which logging implemenatation they prefer as opposed to us mandating a specific framework life log4j.
>
> If noone objects, I can make the slf4j change to POILogger before the 5.0.0 release.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by "fanningpj@apache.org" <fa...@apache.org>.
The POILogger is actually a reasonably good implementation.
default void log(int level, Object... objs) {
if (!check(level)) return;
https://github.com/apache/poi/blob/trunk/src/java/org/apache/poi/util/POILogger.java
This is basically what slf4j and log4j do too. The objs will not be appended into a string if the log level is not required.
I would still favour modifying POILogger to use slf4j under the hood but this saves us having to rewrite all the logging code. If there is a better API than the one above, we can add extra methods to POILogger when needed and switch some logging to use the new methods over time.
I would favour slf4j because users can choose which logging implemenatation they prefer as opposed to us mandating a specific framework life log4j.
If noone objects, I can make the slf4j change to POILogger before the 5.0.0 release.
On Tuesday 8 December 2020, 20:43:35 GMT, Dominik Stadler <do...@gmx.at> wrote:
Hi,
I also see the custom logging functionality unnecessary and outdated,
replacing it with one of the popular log-frameworks would be nice.
However I see POI mostly as a tool-library which usually should only log
very few things, mostly only warnings in some cases when it is being used
incorrectly in some way. We then be able to enable debug logs with some
configuration change to investigate things if necessary.
Choosing the "right" logging framework is hard for me, unfortunately there
are many choices. When building some application, I usually end up with
many different ones dragged in via dependencies. So a solution which uses
one of the small wrappers which can plug into most of the common frameworks
would be nice. I think slf4j can do this as well as commons-logging. Log4J
is the one closes to being the de-facto standard, but would be a bit harder
to integrate into larger applications, although I don't have much
experience with doing this, so it might work well. I would at least try it
before making a decision.
On performance/allocations: we did perform a fair amount of testing of
Apache POI over the years and logging was never a concern as far as I know,
probably because there are very few logging statements in the code anyway.
So you will likely not see much of it compared to other allocations. But
there might be cases where it becomes more prominent.
Thanks... Dominik.
On Sun, Dec 6, 2020 at 12:26 AM Dave Fisher <wa...@apache.org> wrote:
> FYI -
>
> POLogger was part of the initial commit of POI to the Apache Jakarta
> project on Jan. 31, 2002.
>
> https://svn.apache.org/viewvc?view=revision&revision=352063 <
> https://svn.apache.org/viewvc?view=revision&revision=352063>
>
> History from svn can be found here:
>
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> <
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> >
>
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> <
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> >
>
> There were many bug fixes, etc.
>
> Regards,
> Dave
>
> > On Dec 5, 2020, at 2:46 PM, Bill Taylor <wa...@alum.mit.edu> wrote:
> >
> > Good idea. I've been through the slf 4 j transition in other places. It
> > is PAINFUL and nobody wants to do it, but the resulting system is a lot
> > better.
> >
> > On Sat, Dec 5, 2020 at 5:36 PM Marius Volkhart <Ma...@volkhart.com>
> wrote:
> >
> >> Hello,
> >>
> >> POI currently uses a custom facility for logging: the POILogger
> interface.
> >> This serves as a level of indirection to allow consumers to plug in a
> >> logging implementation of their own. Best as I can tell, this facility
> was
> >> added nearly 10 years ago, and the logging landscape has changed a lot
> in
> >> that time. I'd like to revisit this facility.
> >>
> >> The impact of temporary objects due to logging has been of increasing
> focus
> >> in the last few years. Projects like Apache Log4J have gone to great
> >> lengths to reduce the number of temporary objects created for logging
> >> purposes, and run garbage-free in some configurations. At this time,
> >> POILogger is comparatively garbage heavy. Every call to
> POILogger.log(int,
> >> Object...) requires at least an Object[] allocation, even if the message
> >> won't be logged. In many cases, string concatenation is done before
> calling
> >> log(int, Object...), resulting in more allocations. The logging
> frameworks
> >> like Log4J have solved this by adding overloads that take a varying
> number
> >> of arguments.
> >>
> >> Once inside of log(int, Object...), if it is determined that the message
> >> should be logged, the common case of a single Object array is not
> optimized
> >> for. Furthermore, the log forging escape regex is compiled every time.
> >>
> >> Despite providing an indirection of it's own, POI still has a hard
> >> dependency on Apache Commons Logging, and ships with a POILogger
> >> implementation that defers to Commons Logging.
> >>
> >> The performance topics could all be addressed without much difficulty.
> The
> >> question I pose is, should they be? Other Apache projects exist to
> focus on
> >> the problem of how to do logging well. I propose that POI uses one of
> the
> >> logging frameworks directly, rather than having the POILogger
> abstraction.
> >> 10 years ago, logging frameworks didn't split their API and backend the
> way
> >> that Log4J and SLF4J/Logback do today, so the need for an indirection
> was
> >> greater.
> >>
> >> Commons Logging is already a dependency, so it may seem a logical
> choice is
> >> to use it directly. However, Commons Logging has a very limited API,
> which
> >> would make POI authors write more logging code than they do now. It also
> >> suffers from high garbage.
> >>
> >> Instead, I propose that Log4J is the more logical choice. It's a popular
> >> logging framework, under the Apache umbrella, and is a leader when it
> comes
> >> to considering performance while providing rich logging APIs. Using the
> >> Log4J API lets application authors decide if they want to use Logback,
> >> Log4J Core, or some other logging backend, and gives them a lot of
> >> flexibility in how logging is done.
> >>
> >> Of course, removing POILogger is an API change. However, it is marked as
> >> being @Internal, and previous discussion
> >> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there
> are
> >> unlikely to be many users of this API. This feels like a change that
> could
> >> happen after the 5.0 release.
> >>
> >> I would like to complete this work, and would also write new
> documentation
> >> to explain how POI submits log events to the Log4J API.
> >>
> >> Proposed changes:
> >> - Remove Commons Logging dependency
> >> - Add Log4J API dependency
> >> - Remove POILogger API
> >> - Remove POILogFactory API
> >> - Modify all log sites to use Log4J API
> >> - Write new documentation for how POI submits events
> >>
> >> --
> >> Cheers,
> >> Marius Volkhart
> >>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by Dominik Stadler <do...@gmx.at>.
Hi,
I also see the custom logging functionality unnecessary and outdated,
replacing it with one of the popular log-frameworks would be nice.
However I see POI mostly as a tool-library which usually should only log
very few things, mostly only warnings in some cases when it is being used
incorrectly in some way. We then be able to enable debug logs with some
configuration change to investigate things if necessary.
Choosing the "right" logging framework is hard for me, unfortunately there
are many choices. When building some application, I usually end up with
many different ones dragged in via dependencies. So a solution which uses
one of the small wrappers which can plug into most of the common frameworks
would be nice. I think slf4j can do this as well as commons-logging. Log4J
is the one closes to being the de-facto standard, but would be a bit harder
to integrate into larger applications, although I don't have much
experience with doing this, so it might work well. I would at least try it
before making a decision.
On performance/allocations: we did perform a fair amount of testing of
Apache POI over the years and logging was never a concern as far as I know,
probably because there are very few logging statements in the code anyway.
So you will likely not see much of it compared to other allocations. But
there might be cases where it becomes more prominent.
Thanks... Dominik.
On Sun, Dec 6, 2020 at 12:26 AM Dave Fisher <wa...@apache.org> wrote:
> FYI -
>
> POLogger was part of the initial commit of POI to the Apache Jakarta
> project on Jan. 31, 2002.
>
> https://svn.apache.org/viewvc?view=revision&revision=352063 <
> https://svn.apache.org/viewvc?view=revision&revision=352063>
>
> History from svn can be found here:
>
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> <
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log
> >
>
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> <
> https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log
> >
>
> There were many bug fixes, etc.
>
> Regards,
> Dave
>
> > On Dec 5, 2020, at 2:46 PM, Bill Taylor <wa...@alum.mit.edu> wrote:
> >
> > Good idea. I've been through the slf 4 j transition in other places. It
> > is PAINFUL and nobody wants to do it, but the resulting system is a lot
> > better.
> >
> > On Sat, Dec 5, 2020 at 5:36 PM Marius Volkhart <Ma...@volkhart.com>
> wrote:
> >
> >> Hello,
> >>
> >> POI currently uses a custom facility for logging: the POILogger
> interface.
> >> This serves as a level of indirection to allow consumers to plug in a
> >> logging implementation of their own. Best as I can tell, this facility
> was
> >> added nearly 10 years ago, and the logging landscape has changed a lot
> in
> >> that time. I'd like to revisit this facility.
> >>
> >> The impact of temporary objects due to logging has been of increasing
> focus
> >> in the last few years. Projects like Apache Log4J have gone to great
> >> lengths to reduce the number of temporary objects created for logging
> >> purposes, and run garbage-free in some configurations. At this time,
> >> POILogger is comparatively garbage heavy. Every call to
> POILogger.log(int,
> >> Object...) requires at least an Object[] allocation, even if the message
> >> won't be logged. In many cases, string concatenation is done before
> calling
> >> log(int, Object...), resulting in more allocations. The logging
> frameworks
> >> like Log4J have solved this by adding overloads that take a varying
> number
> >> of arguments.
> >>
> >> Once inside of log(int, Object...), if it is determined that the message
> >> should be logged, the common case of a single Object array is not
> optimized
> >> for. Furthermore, the log forging escape regex is compiled every time.
> >>
> >> Despite providing an indirection of it's own, POI still has a hard
> >> dependency on Apache Commons Logging, and ships with a POILogger
> >> implementation that defers to Commons Logging.
> >>
> >> The performance topics could all be addressed without much difficulty.
> The
> >> question I pose is, should they be? Other Apache projects exist to
> focus on
> >> the problem of how to do logging well. I propose that POI uses one of
> the
> >> logging frameworks directly, rather than having the POILogger
> abstraction.
> >> 10 years ago, logging frameworks didn't split their API and backend the
> way
> >> that Log4J and SLF4J/Logback do today, so the need for an indirection
> was
> >> greater.
> >>
> >> Commons Logging is already a dependency, so it may seem a logical
> choice is
> >> to use it directly. However, Commons Logging has a very limited API,
> which
> >> would make POI authors write more logging code than they do now. It also
> >> suffers from high garbage.
> >>
> >> Instead, I propose that Log4J is the more logical choice. It's a popular
> >> logging framework, under the Apache umbrella, and is a leader when it
> comes
> >> to considering performance while providing rich logging APIs. Using the
> >> Log4J API lets application authors decide if they want to use Logback,
> >> Log4J Core, or some other logging backend, and gives them a lot of
> >> flexibility in how logging is done.
> >>
> >> Of course, removing POILogger is an API change. However, it is marked as
> >> being @Internal, and previous discussion
> >> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there
> are
> >> unlikely to be many users of this API. This feels like a change that
> could
> >> happen after the 5.0 release.
> >>
> >> I would like to complete this work, and would also write new
> documentation
> >> to explain how POI submits log events to the Log4J API.
> >>
> >> Proposed changes:
> >> - Remove Commons Logging dependency
> >> - Add Log4J API dependency
> >> - Remove POILogger API
> >> - Remove POILogFactory API
> >> - Modify all log sites to use Log4J API
> >> - Write new documentation for how POI submits events
> >>
> >> --
> >> Cheers,
> >> Marius Volkhart
> >>
>
>
Re: Logging
Posted by Dave Fisher <wa...@apache.org>.
FYI -
POLogger was part of the initial commit of POI to the Apache Jakarta project on Jan. 31, 2002.
https://svn.apache.org/viewvc?view=revision&revision=352063 <https://svn.apache.org/viewvc?view=revision&revision=352063>
History from svn can be found here:
https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log <https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogFactory.java?view=log>
https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log <https://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/util/POILogger.java?view=log>
There were many bug fixes, etc.
Regards,
Dave
> On Dec 5, 2020, at 2:46 PM, Bill Taylor <wa...@alum.mit.edu> wrote:
>
> Good idea. I've been through the slf 4 j transition in other places. It
> is PAINFUL and nobody wants to do it, but the resulting system is a lot
> better.
>
> On Sat, Dec 5, 2020 at 5:36 PM Marius Volkhart <Ma...@volkhart.com> wrote:
>
>> Hello,
>>
>> POI currently uses a custom facility for logging: the POILogger interface.
>> This serves as a level of indirection to allow consumers to plug in a
>> logging implementation of their own. Best as I can tell, this facility was
>> added nearly 10 years ago, and the logging landscape has changed a lot in
>> that time. I'd like to revisit this facility.
>>
>> The impact of temporary objects due to logging has been of increasing focus
>> in the last few years. Projects like Apache Log4J have gone to great
>> lengths to reduce the number of temporary objects created for logging
>> purposes, and run garbage-free in some configurations. At this time,
>> POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
>> Object...) requires at least an Object[] allocation, even if the message
>> won't be logged. In many cases, string concatenation is done before calling
>> log(int, Object...), resulting in more allocations. The logging frameworks
>> like Log4J have solved this by adding overloads that take a varying number
>> of arguments.
>>
>> Once inside of log(int, Object...), if it is determined that the message
>> should be logged, the common case of a single Object array is not optimized
>> for. Furthermore, the log forging escape regex is compiled every time.
>>
>> Despite providing an indirection of it's own, POI still has a hard
>> dependency on Apache Commons Logging, and ships with a POILogger
>> implementation that defers to Commons Logging.
>>
>> The performance topics could all be addressed without much difficulty. The
>> question I pose is, should they be? Other Apache projects exist to focus on
>> the problem of how to do logging well. I propose that POI uses one of the
>> logging frameworks directly, rather than having the POILogger abstraction.
>> 10 years ago, logging frameworks didn't split their API and backend the way
>> that Log4J and SLF4J/Logback do today, so the need for an indirection was
>> greater.
>>
>> Commons Logging is already a dependency, so it may seem a logical choice is
>> to use it directly. However, Commons Logging has a very limited API, which
>> would make POI authors write more logging code than they do now. It also
>> suffers from high garbage.
>>
>> Instead, I propose that Log4J is the more logical choice. It's a popular
>> logging framework, under the Apache umbrella, and is a leader when it comes
>> to considering performance while providing rich logging APIs. Using the
>> Log4J API lets application authors decide if they want to use Logback,
>> Log4J Core, or some other logging backend, and gives them a lot of
>> flexibility in how logging is done.
>>
>> Of course, removing POILogger is an API change. However, it is marked as
>> being @Internal, and previous discussion
>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
>> unlikely to be many users of this API. This feels like a change that could
>> happen after the 5.0 release.
>>
>> I would like to complete this work, and would also write new documentation
>> to explain how POI submits log events to the Log4J API.
>>
>> Proposed changes:
>> - Remove Commons Logging dependency
>> - Add Log4J API dependency
>> - Remove POILogger API
>> - Remove POILogFactory API
>> - Modify all log sites to use Log4J API
>> - Write new documentation for how POI submits events
>>
>> --
>> Cheers,
>> Marius Volkhart
>>
Re: Logging
Posted by Bill Taylor <wa...@alum.mit.edu>.
Good idea. I've been through the slf 4 j transition in other places. It
is PAINFUL and nobody wants to do it, but the resulting system is a lot
better.
On Sat, Dec 5, 2020 at 5:36 PM Marius Volkhart <Ma...@volkhart.com> wrote:
> Hello,
>
> POI currently uses a custom facility for logging: the POILogger interface.
> This serves as a level of indirection to allow consumers to plug in a
> logging implementation of their own. Best as I can tell, this facility was
> added nearly 10 years ago, and the logging landscape has changed a lot in
> that time. I'd like to revisit this facility.
>
> The impact of temporary objects due to logging has been of increasing focus
> in the last few years. Projects like Apache Log4J have gone to great
> lengths to reduce the number of temporary objects created for logging
> purposes, and run garbage-free in some configurations. At this time,
> POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
> Object...) requires at least an Object[] allocation, even if the message
> won't be logged. In many cases, string concatenation is done before calling
> log(int, Object...), resulting in more allocations. The logging frameworks
> like Log4J have solved this by adding overloads that take a varying number
> of arguments.
>
> Once inside of log(int, Object...), if it is determined that the message
> should be logged, the common case of a single Object array is not optimized
> for. Furthermore, the log forging escape regex is compiled every time.
>
> Despite providing an indirection of it's own, POI still has a hard
> dependency on Apache Commons Logging, and ships with a POILogger
> implementation that defers to Commons Logging.
>
> The performance topics could all be addressed without much difficulty. The
> question I pose is, should they be? Other Apache projects exist to focus on
> the problem of how to do logging well. I propose that POI uses one of the
> logging frameworks directly, rather than having the POILogger abstraction.
> 10 years ago, logging frameworks didn't split their API and backend the way
> that Log4J and SLF4J/Logback do today, so the need for an indirection was
> greater.
>
> Commons Logging is already a dependency, so it may seem a logical choice is
> to use it directly. However, Commons Logging has a very limited API, which
> would make POI authors write more logging code than they do now. It also
> suffers from high garbage.
>
> Instead, I propose that Log4J is the more logical choice. It's a popular
> logging framework, under the Apache umbrella, and is a leader when it comes
> to considering performance while providing rich logging APIs. Using the
> Log4J API lets application authors decide if they want to use Logback,
> Log4J Core, or some other logging backend, and gives them a lot of
> flexibility in how logging is done.
>
> Of course, removing POILogger is an API change. However, it is marked as
> being @Internal, and previous discussion
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
> unlikely to be many users of this API. This feels like a change that could
> happen after the 5.0 release.
>
> I would like to complete this work, and would also write new documentation
> to explain how POI submits log events to the Log4J API.
>
> Proposed changes:
> - Remove Commons Logging dependency
> - Add Log4J API dependency
> - Remove POILogger API
> - Remove POILogFactory API
> - Modify all log sites to use Log4J API
> - Write new documentation for how POI submits events
>
> --
> Cheers,
> Marius Volkhart
>
Re: Logging
Posted by Axel Howind <ax...@dua3.com>.
Hi Andi,
two more things to consider:
- Jigsaw support. The module system has been around for some years now, and libraries still have to fully support it. From what I read, Log4J2 seems to support Jigsaw, whereas SLF4J/Logback still only has it in Beta-versions.
- Active development. The last SLF4J happened in 2019, about the same time that the last alpha release with Jigsaw support was made. The dev list for both SLF4J and Logback only seems to have three kinds of entries: Someone volunteering to help or asking for same, automatically posted JIRA updates, and Rory O’Donnel announcing the availability of a new JDK build.
So if JUL is not an option, I would definitely go for Log4J2.
Cheers,
Axel
> Am 27.01.2021 um 00:48 schrieb Andreas Beeker <ki...@apache.org>:
>
> Hi Axel,
>
> my ideas against JUL and pro SLF4J / Logback / Log4j 2:
> * I prefer a logging framework which is able to bridge commons logging, as we have dependencies which use commons logging.
> * as a library we should pick a logging framework / stubs, which users typically use - if we use JUL, they likely need to use an additional logging bridge ... I think it's futile to set a KISS trend here :)
>
> Apart of that, I don't think, we would benefit much by performance gains, as logging is not really a POI-thing ...
>
> Andi
>
>
>
> On 26.01.21 23:42, axel@dua3.com wrote:
>> Hi,
>>
>> just want to know what are your thoughts about not using any third party logging framework and instead go with plain JUL logging? Slf4J, Log4J, and all the others had been created to solve shortcomings in JUL. But JUL has much improved, and messages can be created using lambda formatters which gives you really much flexibility.
>>
>> - no non-JDK dependencies needed
>> - whatever logging framework your application uses, it will provide support for integrating JUL
>> - available on all platforms
>>
>> In my personal projects, I have removed the logging frameworks and gone back to JUL and life is much simpler now.
>>
>> Cheers,
>> Axel
>>
>> Von meinem iPhone gesendet
>>
>>> Am 05.12.2020 um 23:36 schrieb Marius Volkhart <Ma...@volkhart.com>:
>>>
>>> Hello,
>>>
>>> POI currently uses a custom facility for logging: the POILogger interface.
>>> This serves as a level of indirection to allow consumers to plug in a
>>> logging implementation of their own. Best as I can tell, this facility was
>>> added nearly 10 years ago, and the logging landscape has changed a lot in
>>> that time. I'd like to revisit this facility.
>>>
>>> The impact of temporary objects due to logging has been of increasing focus
>>> in the last few years. Projects like Apache Log4J have gone to great
>>> lengths to reduce the number of temporary objects created for logging
>>> purposes, and run garbage-free in some configurations. At this time,
>>> POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
>>> Object...) requires at least an Object[] allocation, even if the message
>>> won't be logged. In many cases, string concatenation is done before calling
>>> log(int, Object...), resulting in more allocations. The logging frameworks
>>> like Log4J have solved this by adding overloads that take a varying number
>>> of arguments.
>>>
>>> Once inside of log(int, Object...), if it is determined that the message
>>> should be logged, the common case of a single Object array is not optimized
>>> for. Furthermore, the log forging escape regex is compiled every time.
>>>
>>> Despite providing an indirection of it's own, POI still has a hard
>>> dependency on Apache Commons Logging, and ships with a POILogger
>>> implementation that defers to Commons Logging.
>>>
>>> The performance topics could all be addressed without much difficulty. The
>>> question I pose is, should they be? Other Apache projects exist to focus on
>>> the problem of how to do logging well. I propose that POI uses one of the
>>> logging frameworks directly, rather than having the POILogger abstraction.
>>> 10 years ago, logging frameworks didn't split their API and backend the way
>>> that Log4J and SLF4J/Logback do today, so the need for an indirection was
>>> greater.
>>>
>>> Commons Logging is already a dependency, so it may seem a logical choice is
>>> to use it directly. However, Commons Logging has a very limited API, which
>>> would make POI authors write more logging code than they do now. It also
>>> suffers from high garbage.
>>>
>>> Instead, I propose that Log4J is the more logical choice. It's a popular
>>> logging framework, under the Apache umbrella, and is a leader when it comes
>>> to considering performance while providing rich logging APIs. Using the
>>> Log4J API lets application authors decide if they want to use Logback,
>>> Log4J Core, or some other logging backend, and gives them a lot of
>>> flexibility in how logging is done.
>>>
>>> Of course, removing POILogger is an API change. However, it is marked as
>>> being @Internal, and previous discussion
>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
>>> unlikely to be many users of this API. This feels like a change that could
>>> happen after the 5.0 release.
>>>
>>> I would like to complete this work, and would also write new documentation
>>> to explain how POI submits log events to the Log4J API.
>>>
>>> Proposed changes:
>>> - Remove Commons Logging dependency
>>> - Add Log4J API dependency
>>> - Remove POILogger API
>>> - Remove POILogFactory API
>>> - Modify all log sites to use Log4J API
>>> - Write new documentation for how POI submits events
>>>
>>> --
>>> Cheers,
>>> Marius Volkhart
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by Andreas Beeker <ki...@apache.org>.
Hi Axel,
my ideas against JUL and pro SLF4J / Logback / Log4j 2:
* I prefer a logging framework which is able to bridge commons logging, as we have dependencies which use commons logging.
* as a library we should pick a logging framework / stubs, which users typically use - if we use JUL, they likely need to use an additional logging bridge ... I think it's futile to set a KISS trend here :)
Apart of that, I don't think, we would benefit much by performance gains, as logging is not really a POI-thing ...
Andi
On 26.01.21 23:42, axel@dua3.com wrote:
> Hi,
>
> just want to know what are your thoughts about not using any third party logging framework and instead go with plain JUL logging? Slf4J, Log4J, and all the others had been created to solve shortcomings in JUL. But JUL has much improved, and messages can be created using lambda formatters which gives you really much flexibility.
>
> - no non-JDK dependencies needed
> - whatever logging framework your application uses, it will provide support for integrating JUL
> - available on all platforms
>
> In my personal projects, I have removed the logging frameworks and gone back to JUL and life is much simpler now.
>
> Cheers,
> Axel
>
> Von meinem iPhone gesendet
>
>> Am 05.12.2020 um 23:36 schrieb Marius Volkhart <Ma...@volkhart.com>:
>>
>> Hello,
>>
>> POI currently uses a custom facility for logging: the POILogger interface.
>> This serves as a level of indirection to allow consumers to plug in a
>> logging implementation of their own. Best as I can tell, this facility was
>> added nearly 10 years ago, and the logging landscape has changed a lot in
>> that time. I'd like to revisit this facility.
>>
>> The impact of temporary objects due to logging has been of increasing focus
>> in the last few years. Projects like Apache Log4J have gone to great
>> lengths to reduce the number of temporary objects created for logging
>> purposes, and run garbage-free in some configurations. At this time,
>> POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
>> Object...) requires at least an Object[] allocation, even if the message
>> won't be logged. In many cases, string concatenation is done before calling
>> log(int, Object...), resulting in more allocations. The logging frameworks
>> like Log4J have solved this by adding overloads that take a varying number
>> of arguments.
>>
>> Once inside of log(int, Object...), if it is determined that the message
>> should be logged, the common case of a single Object array is not optimized
>> for. Furthermore, the log forging escape regex is compiled every time.
>>
>> Despite providing an indirection of it's own, POI still has a hard
>> dependency on Apache Commons Logging, and ships with a POILogger
>> implementation that defers to Commons Logging.
>>
>> The performance topics could all be addressed without much difficulty. The
>> question I pose is, should they be? Other Apache projects exist to focus on
>> the problem of how to do logging well. I propose that POI uses one of the
>> logging frameworks directly, rather than having the POILogger abstraction.
>> 10 years ago, logging frameworks didn't split their API and backend the way
>> that Log4J and SLF4J/Logback do today, so the need for an indirection was
>> greater.
>>
>> Commons Logging is already a dependency, so it may seem a logical choice is
>> to use it directly. However, Commons Logging has a very limited API, which
>> would make POI authors write more logging code than they do now. It also
>> suffers from high garbage.
>>
>> Instead, I propose that Log4J is the more logical choice. It's a popular
>> logging framework, under the Apache umbrella, and is a leader when it comes
>> to considering performance while providing rich logging APIs. Using the
>> Log4J API lets application authors decide if they want to use Logback,
>> Log4J Core, or some other logging backend, and gives them a lot of
>> flexibility in how logging is done.
>>
>> Of course, removing POILogger is an API change. However, it is marked as
>> being @Internal, and previous discussion
>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
>> unlikely to be many users of this API. This feels like a change that could
>> happen after the 5.0 release.
>>
>> I would like to complete this work, and would also write new documentation
>> to explain how POI submits log events to the Log4J API.
>>
>> Proposed changes:
>> - Remove Commons Logging dependency
>> - Add Log4J API dependency
>> - Remove POILogger API
>> - Remove POILogFactory API
>> - Modify all log sites to use Log4J API
>> - Write new documentation for how POI submits events
>>
>> --
>> Cheers,
>> Marius Volkhart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Logging
Posted by "axel@dua3.com" <ax...@dua3.com>.
Hi,
just want to know what are your thoughts about not using any third party logging framework and instead go with plain JUL logging? Slf4J, Log4J, and all the others had been created to solve shortcomings in JUL. But JUL has much improved, and messages can be created using lambda formatters which gives you really much flexibility.
- no non-JDK dependencies needed
- whatever logging framework your application uses, it will provide support for integrating JUL
- available on all platforms
In my personal projects, I have removed the logging frameworks and gone back to JUL and life is much simpler now.
Cheers,
Axel
Von meinem iPhone gesendet
> Am 05.12.2020 um 23:36 schrieb Marius Volkhart <Ma...@volkhart.com>:
>
> Hello,
>
> POI currently uses a custom facility for logging: the POILogger interface.
> This serves as a level of indirection to allow consumers to plug in a
> logging implementation of their own. Best as I can tell, this facility was
> added nearly 10 years ago, and the logging landscape has changed a lot in
> that time. I'd like to revisit this facility.
>
> The impact of temporary objects due to logging has been of increasing focus
> in the last few years. Projects like Apache Log4J have gone to great
> lengths to reduce the number of temporary objects created for logging
> purposes, and run garbage-free in some configurations. At this time,
> POILogger is comparatively garbage heavy. Every call to POILogger.log(int,
> Object...) requires at least an Object[] allocation, even if the message
> won't be logged. In many cases, string concatenation is done before calling
> log(int, Object...), resulting in more allocations. The logging frameworks
> like Log4J have solved this by adding overloads that take a varying number
> of arguments.
>
> Once inside of log(int, Object...), if it is determined that the message
> should be logged, the common case of a single Object array is not optimized
> for. Furthermore, the log forging escape regex is compiled every time.
>
> Despite providing an indirection of it's own, POI still has a hard
> dependency on Apache Commons Logging, and ships with a POILogger
> implementation that defers to Commons Logging.
>
> The performance topics could all be addressed without much difficulty. The
> question I pose is, should they be? Other Apache projects exist to focus on
> the problem of how to do logging well. I propose that POI uses one of the
> logging frameworks directly, rather than having the POILogger abstraction.
> 10 years ago, logging frameworks didn't split their API and backend the way
> that Log4J and SLF4J/Logback do today, so the need for an indirection was
> greater.
>
> Commons Logging is already a dependency, so it may seem a logical choice is
> to use it directly. However, Commons Logging has a very limited API, which
> would make POI authors write more logging code than they do now. It also
> suffers from high garbage.
>
> Instead, I propose that Log4J is the more logical choice. It's a popular
> logging framework, under the Apache umbrella, and is a leader when it comes
> to considering performance while providing rich logging APIs. Using the
> Log4J API lets application authors decide if they want to use Logback,
> Log4J Core, or some other logging backend, and gives them a lot of
> flexibility in how logging is done.
>
> Of course, removing POILogger is an API change. However, it is marked as
> being @Internal, and previous discussion
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=63047> suggests there are
> unlikely to be many users of this API. This feels like a change that could
> happen after the 5.0 release.
>
> I would like to complete this work, and would also write new documentation
> to explain how POI submits log events to the Log4J API.
>
> Proposed changes:
> - Remove Commons Logging dependency
> - Add Log4J API dependency
> - Remove POILogger API
> - Remove POILogFactory API
> - Modify all log sites to use Log4J API
> - Write new documentation for how POI submits events
>
> --
> Cheers,
> Marius Volkhart