Java version usage

As a follow up to Christian’s question, here are the usage statistics I could find for the Java LTS versions Java 8Java 11. Java 17 33& 56%9%.[1] 31% 28%. 19%. [2] Unfortunately, Jetbrains has not published a report for 20

Re: Why is JNDI still necessary?

> 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 you were here. > >> precisely why in 3.x we extracted a LOT

Re: Why is JNDI still necessary?

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 here. > precisely why in 3.x we extracted a LOT of stuff from log4j-core into > their own modules. Why not 2.x? > To be

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

Hi Ralph On Wed, 1 Nov 2023 at 23:53, Ralph Goers wrote: > > On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz > > wrote: > > Actually we don't need a fast formatter either. Except for the rolling > > file manager that can require a date from the past, the layouts format > > timestamps close to 'now

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

> On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz wrote: > > Hi Volkan, > > On Wed, 1 Nov 2023 at 12:07, Volkan Yazıcı wrote: >> Curious: *In the context of logging, does `FastDateParser` need to be fast >> while parsing?* We certainly need to *"format"* the instant fast. Though do >> we really

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

Hi Volkan, On Wed, 1 Nov 2023 at 12:07, Volkan Yazıcı wrote: > Curious: *In the context of logging, does `FastDateParser` need to be fast > while parsing?* We certainly need to *"format"* the instant fast. Though do > we really need to *"parse"* it fast too? No we don't. In Commons Lang the pars

Re: [Log4j] Main website page

Me too. Ralph > On Nov 1, 2023, at 3:02 PM, Matt Sicker wrote: > > Oh, I thought you meant you updated the website itself already. > >> On Nov 1, 2023, at 3:03 PM, Volkan Yazıcı wrote: >> >> It is the last commit to the `logging-log4j2` repository: >> https://github.com/apache/logging-log4j2

Re: Why is JNDI still necessary?

Christian, I was at least 3 years ahead of you on this one.This is precisely why in 3.x we extracted a LOT of stuff from log4j-core into their own modules. To be honest the main driver was JPMS - our goal for 3.x Is for log4j-core to only have a hard dependency on java.base and as few optional d

Re: [Log4j] Main website page

Oh, I thought you meant you updated the website itself already. > On Nov 1, 2023, at 3:03 PM, Volkan Yazıcı wrote: > > It is the last commit to the `logging-log4j2` repository: > https://github.com/apache/logging-log4j2/commit/96eb0d00099b709663a251484f2967cbb93b0230 > > On Wed, Nov 1, 2023 at

Re: Why is JNDI still necessary?

> On Nov 1, 2023, at 2:22 PM, Christian Grobmeier wrote: > > We should not underestimate the impact log4shell had. Jndi was at the epi > center. Us, providing a giant jar including so much stuff with potential > security holes don’t do us a favor. This is exactly why in 3.x, the main branch,

Re: [Log4j] Main website page

It is the last commit to the `logging-log4j2` repository: https://github.com/apache/logging-log4j2/commit/96eb0d00099b709663a251484f2967cbb93b0230 On Wed, Nov 1, 2023 at 5:23 PM Ralph Goers wrote: > The Log4j site or the Logging site? Where can we review this? > > Ralph > > > On Nov 1, 2023, at

Staging is back

Infra helped me to fix the staging website: https://logging.staged.apache.org/ This website is currently done with jekyll. I will restore the sub website in the next days Since the underlying bug is fixed, I don’t expect any more issues. Please check it out and let me know if you have concerns

Re: Why is JNDI still necessary?

As some might know, I am writing a book and the publisher gathers a lot of feedback. Also I talk to many people in my classrooms and also to many pros at my clients side. What I hear is usually: - is log4j really secure? - can’t I disable certain features? - are you sure you get jndi right this

Re: Why is JNDI still necessary?

I don’t see any reason why we shouldn’t publish the JNDI support in its own module as we’re planning in main already. Whether we eventually split out anything from the main repo is another story, but in 3.x, JNDI, like most of the optional features, will require downloading additional dependenci

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

I can’t think of any reason why we’d need fast date parsing. Unless it’s relevant in the rolling file appender family? > On Nov 1, 2023, at 6:07 AM, Volkan Yazıcı wrote: > > As reported in LOG4J2-3672 > , `FastDateParser`[1] > contains `DateFo

Re: [Log4j] Main website page

The Log4j site or the Logging site? Where can we review this? Ralph > On Nov 1, 2023, at 9:07 AM, Volkan Yazıcı wrote: > > Heads up! I have updated the main website page: removed the clutter, added > quick navigation links, and rewrote the pitch for features.

Re: [log4net] Project state

Gary is correct on this. In the past we have broken out the sub-projects under the project activity section and project health sections. You can see that in your own previous reports (and those from Matt and myself). Ralph > On Nov 1, 2023, at 5:48 AM, Gary Gregory wrote: > > Not quite IMO, t

[Log4j] Main website page

Heads up! I have updated the main website page: removed the clutter, added quick navigation links, and rewrote the pitch for features.

Re: [log4net] Project state

Not quite IMO, the "project" here is "Loggging Services". The components inside LS, like Log4j, and so on are different types of items and I don't think we need to address the state of each. It might be nice to do but I do not think it is needed. Gary On Wed, Nov 1, 2023, 7:47 AM Volkan Yazıcı w

Re: Why is JNDI still necessary?

 If you want separate logging config files in an EJB environment using JNDI is pretty much required. The same would be true for any properties needed in the configuration. In any case, despite Piotr saying this is a majority vote, it is not. I will veto any attempt to remove JNDI components

[log4net] Project state

In the board report guidelines , project state is required to be described using the following keywords: - *New:* a top-level project that's just getting started - *Ongoing*, with high, moderate or low activity, which you might

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

As reported in LOG4J2-3672 , `FastDateParser`[1] contains `DateFormatSymbols#getZoneStrings()`, which causes initialization and caching of all time zones, resulting in a ~3MB heap overhead on x86_64. The reporter also provided the PR #1848

Re: Why is JNDI still necessary?

On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote: > There is a difference between a JEE application that only uses servlets > vs one that uses EJBs. At a former employer we often used JBoss to run > servlets even though we had no EJBs. In an environment with EJBs I am > not sure how you can di

Re: Why is JNDI still necessary?

Hi On Tue, Oct 31, 2023, at 23:23, Matt Sicker wrote: > I’m not sure how much people use this deployment model anymore, but > JNDI was and still is at the core of JavaEE (now JakartaEE) dependency > injection APIs. While CDI is the current way of using dependency > injection there, CDI is compa

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

Hi, On Tue, Oct 31, 2023, at 23:53, Ralph Goers wrote: > Deprecation and moving to separate modules are not the same thing at > all. I would be +1 to moving everything on this list that isn’t > outright removed to separate repos. I have stated that several times. I am fully aware of that. Thi