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, a...@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 <mar...@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-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
