Re: [DISCUSS] working around log4j issues
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 > 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 > > 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 > > 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 > > > 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 > > > > 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-unsubscr...@poi.apache.org > > > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [DISCUSS] working around log4j issues
Got it. Makes sense. Thank you. On Sat, Nov 16, 2024 at 2:35 PM PJ Fanning 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 > 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 > 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 > > 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 > > > 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-unsubscr...@poi.apache.org > > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [DISCUSS] working around log4j issues
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 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 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 > 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 > > 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-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [DISCUSS] working around log4j issues
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 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 > 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 > > 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-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [DISCUSS] working around log4j issues
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 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 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-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [DISCUSS] working around log4j issues
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 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-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
