You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by PJ Fanning <fa...@yahoo.com.INVALID> on 2024/11/14 20:44:21 UTC
[DISCUSS] working around log4j issues
I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
Reading
* https://github.com/apache/logging-log4j2/issues/3196
* https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: [DISCUSS] working around log4j issues
Posted by PJ Fanning <fa...@apache.org>.
I've added a failover wrapper for LogManager in XMLBeans.
There are a couple of mistakes here - but that have been modified since:
https://github.com/apache/xmlbeans/commit/89fc0e4e8bd0a95f14ada7afe6901932d3172356
I would suggest that you use this commit as an idea of the change but check the latest code to fully evaluate.
I would appreciate if people could review the changes.
On 2024/11/19 13:33:31 Tim Allison wrote:
> Got it. Makes sense. Thank you.
>
> On Sat, Nov 16, 2024 at 2:35 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
> >
> > Hi Tim,
> > I stand by what I said earlier in the thread: that it is counterproductive to make yet another change to our logging framework - even if it is a return to one we used before. slf4j-api is not immune to making breaking changes.
> > I still argue that we could wrap the logger init so that we can avoid having logger init issues fail POI startup.
> >
> >
> >
> >
> >
> >
> > On Saturday 16 November 2024 at 15:12:14 GMT+1, Tim Allison <ta...@apache.org> wrote:
> >
> >
> >
> >
> >
> > Thank you, PJ, for leading this effort. I completely agree that we
> > can't let log4j cause problems for us, and I like your proposal to
> > wrap log4j. Is going back to slf4j off the table?
> >
> > On Thu, Nov 14, 2024 at 5:06 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
> > >
> > > We've already migrated from our own POILogger that was disabled by default to slf4j and then to log4j - over a relatively short period. Migrating again to java.util.logging would seem to me to me to be pretty strange. I have to admit that I have never come across anything that uses java.util.logging and I tend to run scared of built-in Java features. slf4j and log4j are much more prevalent in the apps and libs that I am familiar with.
> > >
> > > I really do not like log4j but I think we are sort of stuck with it. I would still argue that we need to wrap it to protect our users from it going rogue.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thursday 14 November 2024 at 22:28:19 GMT+1, stanton fisque <sf...@gmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
> > >
> > >
> > > Stanton Fisque
> > > principal technologist
> > > latticeware.com
> > > portland, oregon
> > >
> > > > On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
> > > >
> > > > I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
> > > >
> > > > I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
> > > >
> > > > Reading
> > > > * https://github.com/apache/logging-log4j2/issues/3196
> > > > * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
> > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: [DISCUSS] working around log4j issues
Posted by Tim Allison <ta...@apache.org>.
Got it. Makes sense. Thank you.
On Sat, Nov 16, 2024 at 2:35 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
>
> Hi Tim,
> I stand by what I said earlier in the thread: that it is counterproductive to make yet another change to our logging framework - even if it is a return to one we used before. slf4j-api is not immune to making breaking changes.
> I still argue that we could wrap the logger init so that we can avoid having logger init issues fail POI startup.
>
>
>
>
>
>
> On Saturday 16 November 2024 at 15:12:14 GMT+1, Tim Allison <ta...@apache.org> wrote:
>
>
>
>
>
> Thank you, PJ, for leading this effort. I completely agree that we
> can't let log4j cause problems for us, and I like your proposal to
> wrap log4j. Is going back to slf4j off the table?
>
> On Thu, Nov 14, 2024 at 5:06 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
> >
> > We've already migrated from our own POILogger that was disabled by default to slf4j and then to log4j - over a relatively short period. Migrating again to java.util.logging would seem to me to me to be pretty strange. I have to admit that I have never come across anything that uses java.util.logging and I tend to run scared of built-in Java features. slf4j and log4j are much more prevalent in the apps and libs that I am familiar with.
> >
> > I really do not like log4j but I think we are sort of stuck with it. I would still argue that we need to wrap it to protect our users from it going rogue.
> >
> >
> >
> >
> >
> >
> > On Thursday 14 November 2024 at 22:28:19 GMT+1, stanton fisque <sf...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
> >
> >
> > Stanton Fisque
> > principal technologist
> > latticeware.com
> > portland, oregon
> >
> > > On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
> > >
> > > I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
> > >
> > > I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
> > >
> > > Reading
> > > * https://github.com/apache/logging-log4j2/issues/3196
> > > * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
> >
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] working around log4j issues
Posted by PJ Fanning <fa...@yahoo.com.INVALID>.
Hi Tim,
I stand by what I said earlier in the thread: that it is counterproductive to make yet another change to our logging framework - even if it is a return to one we used before. slf4j-api is not immune to making breaking changes.
I still argue that we could wrap the logger init so that we can avoid having logger init issues fail POI startup.
On Saturday 16 November 2024 at 15:12:14 GMT+1, Tim Allison <ta...@apache.org> wrote:
Thank you, PJ, for leading this effort. I completely agree that we
can't let log4j cause problems for us, and I like your proposal to
wrap log4j. Is going back to slf4j off the table?
On Thu, Nov 14, 2024 at 5:06 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
>
> We've already migrated from our own POILogger that was disabled by default to slf4j and then to log4j - over a relatively short period. Migrating again to java.util.logging would seem to me to me to be pretty strange. I have to admit that I have never come across anything that uses java.util.logging and I tend to run scared of built-in Java features. slf4j and log4j are much more prevalent in the apps and libs that I am familiar with.
>
> I really do not like log4j but I think we are sort of stuck with it. I would still argue that we need to wrap it to protect our users from it going rogue.
>
>
>
>
>
>
> On Thursday 14 November 2024 at 22:28:19 GMT+1, stanton fisque <sf...@gmail.com> wrote:
>
>
>
>
>
> would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
>
>
> Stanton Fisque
> principal technologist
> latticeware.com
> portland, oregon
>
> > On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
> >
> > I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
> >
> > I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
> >
> > Reading
> > * https://github.com/apache/logging-log4j2/issues/3196
> > * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: [DISCUSS] working around log4j issues
Posted by Tim Allison <ta...@apache.org>.
Thank you, PJ, for leading this effort. I completely agree that we
can't let log4j cause problems for us, and I like your proposal to
wrap log4j. Is going back to slf4j off the table?
On Thu, Nov 14, 2024 at 5:06 PM PJ Fanning <fa...@yahoo.com.invalid> wrote:
>
> We've already migrated from our own POILogger that was disabled by default to slf4j and then to log4j - over a relatively short period. Migrating again to java.util.logging would seem to me to me to be pretty strange. I have to admit that I have never come across anything that uses java.util.logging and I tend to run scared of built-in Java features. slf4j and log4j are much more prevalent in the apps and libs that I am familiar with.
>
> I really do not like log4j but I think we are sort of stuck with it. I would still argue that we need to wrap it to protect our users from it going rogue.
>
>
>
>
>
>
> On Thursday 14 November 2024 at 22:28:19 GMT+1, stanton fisque <sf...@gmail.com> wrote:
>
>
>
>
>
> would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
>
>
> Stanton Fisque
> principal technologist
> latticeware.com
> portland, oregon
>
> > On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
> >
> > I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
> >
> > I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
> >
> > Reading
> > * https://github.com/apache/logging-log4j2/issues/3196
> > * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] working around log4j issues
Posted by PJ Fanning <fa...@yahoo.com.INVALID>.
We've already migrated from our own POILogger that was disabled by default to slf4j and then to log4j - over a relatively short period. Migrating again to java.util.logging would seem to me to me to be pretty strange. I have to admit that I have never come across anything that uses java.util.logging and I tend to run scared of built-in Java features. slf4j and log4j are much more prevalent in the apps and libs that I am familiar with.
I really do not like log4j but I think we are sort of stuck with it. I would still argue that we need to wrap it to protect our users from it going rogue.
On Thursday 14 November 2024 at 22:28:19 GMT+1, stanton fisque <sf...@gmail.com> wrote:
would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
Stanton Fisque
principal technologist
latticeware.com
portland, oregon
> On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
>
> I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
>
> I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
>
> Reading
> * https://github.com/apache/logging-log4j2/issues/3196
> * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: [DISCUSS] working around log4j issues
Posted by stanton fisque <sf...@gmail.com>.
would there be value in refactoring out log4j completely and just using JUL? is POI actually leveraging any exotic features of log4j or is this a leftover from the days before JUL existed?
Stanton Fisque
principal technologist
latticeware.com
portland, oregon
> On Nov 14, 2024, at 12:44 PM, PJ Fanning <fa...@yahoo.com.INVALID> wrote:
>
> I'm going to suggest that we create a new POI LogManager that wraps the log4j one. This would catch null loggers and log4j exceptions and replace them with a no-op logger instance. We can print to system.err to notify that we have done this.
>
> I don't think log4j issues should allowed to make POI fail completely. I'm afraid that we have to assume that log4j is not reliable.
>
> Reading
> * https://github.com/apache/logging-log4j2/issues/3196
> * https://lists.apache.org/thread/2fpkq93hvdz5ox8w6cqt7sbjrc0x66z6
>
> ---------------------------------------------------------------------
> 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