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 <fannin...@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 > > <talli...@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 <fannin...@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 > > > <sfis...@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 <fannin...@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-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
