Re: [logging-log4j2] 02/02: [LOG4J2-3026] WatchManager does not stop its ConfigurationScheduler thereby leaking a thread.

Furthermore, you moved everything around in the file which makes it extremely difficult to validate what you actually changed. Please revert this and create a PR that can be reviewed with only the required changes. Ralph > On Feb 24, 2021, at 8:07 PM, Ralph Goers wrote: > > Please see my

Re: [logging-log4j2] 02/02: [LOG4J2-3026] WatchManager does not stop its ConfigurationScheduler thereby leaking a thread.

Please see my comments on the Jira issue. Without an explanation of how this accomplishes anything I am -1 on this patch. Ralph > On Feb 24, 2021, at 2:11 PM, ggreg...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > ggregory pushed a commit to

Re: FastDateParser

Sorry about the formatting copied on Windows/emailed/Pasted on Mac in gmail. Corporate policies... G On Wed, Feb 24, 2021 at 12:18 PM Ralph Goers wrote: > > Formatting sucks but thanks! > > Ralph > > > On Feb 24, 2021, at 9:42 AM, Gary Gregory wrote: > > > > Voila: > > > >

Re: FastDateParser

Formatting sucks but thanks! Ralph > On Feb 24, 2021, at 9:42 AM, Gary Gregory wrote: > > Voila: > > org.apache.logging.log4j.core.util.datetime (Java 16) > > org.apache.logging.log4j.core.util.datetime.FastDateParserTest > >

Re: FastDateParser

Voila: org.apache.logging.log4j.core.util.datetime (Java 16) org.apache.logging.log4j.core.util.datetime.FastDateParserTest testLocales_Long_AD(org.apache.logging.log4j.core.util.datetime.FastDateParserTest) java.lang.AssertionError: sr__#Cyrl н. е./2003/фебруар/0009/0007//00/по

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

I have no problem telling people that I use Log4j and that they should stop using slf4j. I've been bitten by slf4j breaking compatibility in to many debugging sessions. Upgrading from one slf4j version to the next is like stepping into a minefield blindfolded wearing earplugs. Gary On Wed, Feb

Re: What is going on with Master?

The StatusLogger has various listeners attached. I think adding and removing listeners on startup and shutdown of a LoggerContext might be a potential way to do this? On Wed, 24 Feb 2021 at 01:07, Tim Perry wrote: > > Ralph, > > Thanks for the review. Yep, that *is* a problem...I knew it was a

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

The fact that it is labeled an alpha release isn’t surprising. It took Ceki almost 6 years to get Logback from 0.x releases to 1.0. To support this we would have to create an slf4j-impl-2.0 module like we had to for 1.8, which means we will have to support 3 variations despite SLF4J “always

Re: FastDateParser

Thanks for checking. Can you provide details? Ralph > On Feb 24, 2021, at 8:16 AM, Gary Gregory wrote: > > In 2.x git, the datetime package fails 9 tests under Java 16 EA 36. > > On Wed, Feb 24, 2021, 01:49 Ralph Goers wrote: > >> Gary, >> >> As you know our FastDateParser was borrowed

Re: FastDateParser

In 2.x git, the datetime package fails 9 tests under Java 16 EA 36. On Wed, Feb 24, 2021, 01:49 Ralph Goers wrote: > Gary, > > As you know our FastDateParser was borrowed from Apache Commons and > modified for our purposes. You picked up bug fixes from Apache Commons > several years ago. > > I

Re: LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

The slf4j API is used very widely, I don't think it's a reasonable solution to suggest people migrate their code (and dependencies) to our API. That said, I'm not sure how important it is for us to support each alpha version of slf4j, considering it doesn't appear to be moving toward a

LOG4J2-2975 What to do with SLF4J 2.0.0 LoggingEventAware

In LOG4J2-2975 , the user tries to run SLF4J fluent API (introduced in 2.0.0-alpha) against log4j-slf4j18-impl. Due to missing LoggingEventAware implementation, source location is not captured right. What shall we do? Keep on telling people to