Logging

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging

Marius Volkhart
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
Reply | Threaded
Open this post in threaded view
|

Re: Logging

Bill Taylor
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

David Fisher-6
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 <[hidden email]> 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 <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: Logging

Dominik Stadler
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

fanningpj@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Logging

kiwiwings
+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, [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Logging

Marius Volkhart
In reply to this post by fanningpj@apache.org
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 [hidden email] <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

kiwiwings
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Logging

PJ Fanning
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Logging

Dominik Stadler
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 <[hidden email]>
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 <
> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

Marius Volkhart
+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 <[hidden email]>
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 <[hidden email]>
> 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 <
> > [hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

Alain FAGOT BÉAREZ
In reply to this post by Dominik Stadler
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 <[hidden email]> 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
><[hidden email]>
>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 <
>> [hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Logging

Axel Howind
In reply to this post by Marius Volkhart
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 <[hidden email]>:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Logging

kiwiwings
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, [hidden email] 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 <[hidden email]>:
>>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Logging

Axel Howind
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 <[hidden email]>:
>
> 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, [hidden email] 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 <[hidden email]>:
>>>
>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]