Re: Features for 3.x was: Why is JNDI still necessary?

2023-11-03 Thread Christian Grobmeier
On Fri, Nov 3, 2023, at 22:28, Ralph Goers wrote: >> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier >> wrote: >> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like >> it was something new. I understand this is nothing new. So, what exactly are >> we aiming at that j

Re: Features for 3.x was: Why is JNDI still necessary?

2023-11-03 Thread Ralph Goers
> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier wrote: > > On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote: >>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier >>> wrote: >>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote: Log4j 3 matching Spring 3 seems obviously a good thing t

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

2023-11-03 Thread Gary Gregory
Hi Volkan, I only care about XML. Gary On Fri, Nov 3, 2023, 3:27 PM Volkan Yazıcı wrote: > Gary, do you want to keep all Jackson modules or just XmlLayout? > > -- Forwarded message - > From: Volkan Yazıcı > Date: Thu, 2 Nov 2023 at 16:43 > Subject: Re: [Discuss]: [VOTE] Depre

Re: Features for 3.x was: Why is JNDI still necessary?

2023-11-03 Thread Christian Grobmeier
On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote: >> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier >> wrote: >> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote: >>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java >>> 17 seems to me as well a good thing. >>> >>> O

[Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

2023-11-03 Thread Volkan Yazıcı
Gary, do you want to keep all Jackson modules or just XmlLayout? -- Forwarded message - From: Volkan Yazıcı Date: Thu, 2 Nov 2023 at 16:43 Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x To: On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers wrote

Re: Deterministic formatter

2023-11-03 Thread Matt Sicker
Alright, after looking at the differences, I’m strongly in favor of the Palantir version. The differences in how it handles lambdas solves one of the main complaints I ever had about the Google version. > On Oct 25, 2023, at 11:47 PM, Piotr P. Karwasz > wrote: > > Hi Matt, > > On Thu, 26 Oct

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

2023-11-03 Thread Gary Gregory
Yes but I'm not sure if that's the API I found way back when I needed to create a MongoDB appender. At the time, the projects I found was not fully baked and I did not think there was a sensible option for a JDBC for NoSQL. Gary On Fri, Nov 3, 2023, 1:50 PM Matt Sicker wrote: > Gary, have you e

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

2023-11-03 Thread Matt Sicker
Gary, have you ever heard of JNoSQL before? It’s basically a JDBC-like effort to create a generic NoSQL API. Been around for a few years at least, and I had considered adding an appender for this back when I learned about it, but I think this was by the point where I sto

Re: Features for 3.x was: Why is JNDI still necessary?

2023-11-03 Thread Matt Sicker
I believe there is confusion here as to what level of compatibility requirements we set at the release of 3.0.0. Some remaining changes proposed for 3.x are technically breaking changes depending on the level of API stability in question. Personally, I think we should demarcate what APIs are tr

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

2023-11-03 Thread Gary Gregory
What I mean is this: When I want to work with a DB-like thing from Java, I look 1st for a JDBC driver, when there is no FOSS option, I have to use a DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store but there are commercial JDBC drivers IIRC. All of this to say that I feel

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

2023-11-03 Thread Volkan Yazıcı
Done. On Thu, Nov 2, 2023 at 6:58 PM Piotr P. Karwasz wrote: > Hi Volkan, > > On Thu, 2 Nov 2023 at 18:50, Volkan Yazıcı wrote: > > > > I guess the safest alternative would be to lazily initialize the > > `FastDateFormat#parser` field. > > I am happy we agree on the right solution, respectful o