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

Hi Ralph, On Thu, 2 Nov 2023 at 05:53, Ralph Goers wrote: > JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to > use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only > supports Java 11 and is really where we want to focus our attention. I wish > everyo

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

Hi Ralph, On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz wrote: > Hi Ralph, > On Thu, 2 Nov 2023 at 05:53, Ralph Goers wrote: > > JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to > > use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only > > supports Ja

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

I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.

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

*Conclusion:* I will make time zone parsing in `FastDateParser` *slow* to avoid `getZoneStrings()`. *Remark:* JTL has the most versatile `Instant` formatter combining `FixedDateFormat`, `FastDateFormat`, and `DateTimeFormatter`. See `InstantFormatter` for why and how. I will later hoist this up to

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

Hi Ralph, On Thu, 2 Nov 2023 at 09:42, Apache wrote: > I’m confused. 3.0.0 hasn’t even been released so how can I be preventing > adding anything. Personally I would prefer the monitoring to be in a separate > repo but I am ok with adding it to the main build. IAM all for moving async > out bu

Re: [log4net] Project state

Hi Volkan That's just me replying wrongly ): I stand by what I said though. -d On 2023/11/02 11:13, Volkan Yazıcı wrote: Davyd, would you mind sharing why you didn't want to send this response to the mailing list? If there are no particular reasons, could you send it there too, please? On W

Re: Why is JNDI still necessary?

On Thu, Nov 2, 2023, at 08:53, Ralph Goers wrote: >> On Nov 1, 2023, at 9:24 PM, Christian Grobmeier wrote: >> >> >> >> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote: >>> Christian, I was at least 3 years ahead of you on this one.This is >> >> Sorry I was not active for a while. Good yo

Re: Java version usage

FWIW, at work, we have been conservative with Java version requirements for a long time, mostly because some of our customers run on old school hardware. So it's been Java 8 forever. But, we have have just completed the migration to Java 17 for the three products I work on. Gary On Thu, Nov 2, 20

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

Piotr, I haven’t committed much to 3.x since June because it already has everything I set out to do. It is everyone else who keeps adding crap that “must” be done before it can be released. Yet another year is far too long. If that is the case my vote is to skip the additional stuff. And I will

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

I should add that I am concerned that we are missing a huge opportunity with Spring 3. A lot of folks will start their migration to Spring 3 early next year. Tying Log4J 3.x to that is a big opportunity for people to upgrade at the same time. Ralph > On Nov 2, 2023, at 3:53 AM, Ralph Goers wr

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

Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java 17 seems to me as well a good thing. Gary On Thu, Nov 2, 2023, 7:04 AM Ralph Goers wrote: > I should add that I am concerned that we are missing a huge opportunity > with Spring 3. A lot of folks will start their migrat

Re: Why is JNDI still necessary?

JPMS is something to work _around_, not _with_ IMO. Gary On Thu, Nov 2, 2023, 12:25 AM Christian Grobmeier wrote: > > > On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote: > > Christian, I was at least 3 years ahead of you on this one.This is > > Sorry I was not active for a while. Good you were

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

My votes: On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz wrote: > > This is a vote to deprecate the following `2.x` modules and features > and remove them from the `3.x` release: > > * `log4j-cassandra`: -0: Prefer keeping since there is no official JDBC access that I know of but I have not lo

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

Gary, a couple of comments: 1. I don’t understand what “there is no official JDBC access” has to do with Cassandra or CouchDB. Could you please elaborate? 2. The functionality in log4j-spring-boot is directly incorporated into Spring 3 due to a PR I submitted. So with Spring Boot 3 log4j-spring-

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

Hi Gary, On Thu, 2 Nov 2023 at 15:42, Gary Gregory wrote: > > * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > -1: I want the ability to log to XML (narrow use-case, sure, but handy). Does it really need to be Jackson? Jackson is optimized for JSON, we can easily write a SAX, StAX

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

I deleted all date parsing functionality in Log4j[1] and the compilation... [drum roll...] succeeded. I am inclined to commit this breaking change. We can refer users who were previously using Log4j to parse dates (ugh!) to Commons Lang. The API is identical, they simply need to use a separate pack

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

On 2023/11/02 15:05:05 "Piotr P. Karwasz" wrote: > Hi Gary, > > On Thu, 2 Nov 2023 at 15:42, Gary Gregory wrote: > > > * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > > -1: I want the ability to log to XML (narrow use-case, sure, but handy). > > Does it really need to be Jackson?

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

On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers wrote: > > On Nov 2, 2023, at 7:42 AM, Gary Gregory wrote: > > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz > >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout) > > -1: I want the ability to log to XML (narrow use-case, sure, but handy).

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

+1 to this change. Ralph > On Nov 2, 2023, at 8:16 AM, Volkan Yazıcı wrote: > > I deleted all date parsing functionality in Log4j[1] and the compilation... > [drum roll...] succeeded. I am inclined to commit this breaking change. We > can refer users who were previously using Log4j to parse dat

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

Hi Gary, On Thu, 2 Nov 2023 at 16:30, Gary D. Gregory wrote: > On 2023/11/02 15:05:05 "Piotr P. Karwasz" wrote: > > On Thu, 2 Nov 2023 at 15:42, Gary Gregory wrote: > > > > * `log4j-spring-boot`: > > > -1: Spring seems too important. > > > > Are you sure you want to _veto_ a module removal base

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

Gary, As a reminder, a +1 vote means that the component will be marked deprecated in 2.x and removed in 3.x. This seems appropriate for log4j-spring-boot as users of Spring upgrading to Log4j 3.x will almost surely be on Spring Boot 3. Ralph > On Nov 2, 2023, at 8:55 AM, Piotr P. Karwasz wro

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

IMO JSONLayout should be deprecated for 2 reasons: 1. JTL is so much better 2. It doesn’t generate great JSON. As for the YAMLLayout, I have no idea who would want that. If they did there has got to be a better solution than using Jackson. To be honest, it would be great if JTL could be gene

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

Hi Volkan, On Thu, 2 Nov 2023 at 16:16, Volkan Yazıcı wrote: > I deleted all date parsing functionality in Log4j[1] and the compilation... > [drum roll...] succeeded. I am inclined to commit this breaking change. We > can refer users who were previously using Log4j to parse dates (ugh!) to > Comm

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

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. > > Gary > > On Thu, Nov 2, 2023, 7:04 AM Ralph Goers wrote: > >> I should add that I am concerned that we are missing a huge o

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

Hi Ralph, On Thu, 2 Nov 2023 at 11:53, Ralph Goers wrote: > Releases do not have to be perfect. In fact, someone advised me once that you > don’t want them to be as that is how you draw in new committers. I don't know about that, all you got from Log4Shell is one lousy committer. And that was a

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

Votes below > On Oct 30, 2023, at 3:44 AM, Piotr P. Karwasz wrote: > > This is a vote to deprecate the following `2.x` modules and features > and remove them from the `3.x` release: > > * `log4j-cassandra`: +1 deprecate > * CouchDB appender: +1 deprecate > * `log4j-docker` -0 > * GELF appender:

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

What’s great about JTL is that it generates valid YAML, too! YAML is a superset of JSON. :) > On Nov 2, 2023, at 11:15 AM, Ralph Goers wrote: > > IMO JSONLayout should be deprecated for 2 reasons: > 1. JTL is so much better > 2. It doesn’t generate great JSON. > > As for the YAMLLayout, I

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

I guess the safest alternative would be to lazily initialize the `FastDateFormat#parser` field. Nevertheless, I do not want to miss this deprecation unicorn, and hence, deleted the code and some tests

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

If we actually annotate the various public APIs like how JUnit 5 does, then we could have more flexibility to remove things. > On Nov 2, 2023, at 4:10 AM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Thu, 2 Nov 2023 at 09:42, Apache wrote: >> I’m confused. 3.0.0 hasn’t even been released so h

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

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 of the public API! Now you have my blessing to shred those unused classes to pi

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

> 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. >> >> Gary >> >> On Thu, Nov 2, 2023, 7:04 AM Ralph Go