Java version usage

[Ralph Goers]

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 2023 - 
https://www.jetbrains.com/lp/devecosystem-2022/java/.

FWiW, I tend to believe New Relic’s numbers over JRebel since it was measured 
from applications actually using their product instead of a survey, but I do 
wish there was a third survey to compare them to.
I am expecting that the usage of Java 17 is going to grow very quickly and Java 
8 will likely go below my 10% threshold by 2025.

Ralph


1. https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem
2. https://www.jrebel.com/success/java-developer-productivity-report-2023

Re: Why is JNDI still necessary?

[Ralph Goers]

> 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 of stuff from log4j-core into 
>> their own modules. 
> 
> Why not 2.x? 
> 
>> 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 dependencies as possible. 
> 
> I understand, Jpms support was added to 2.x recently. Can we do the same 
> thing for 2.x?
> 
>> So when Log4Shell hit we 
>> moved all the JNDI stuff out of log4j-core AND require a property to be 
>> set to use it even if you include the jar containing the JNDI support. 
>> In addition, JNDI can now only access the java protocol or no protocol. 
>> So yes, it is very safe now.
> 
> In this case we need to improve our communication a lot. The main website is 
> still showing all cves and I didn’t find the information easily that I just 
> asked for.
> As you mentioned, this issue is history for three years but the website still 
> looks like all hell is loose.

The main web site is for 2.x. See https://logging.apache.org/log4j/3.x//

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 everyone would 
agree with this so we could get 3.0.0 GA out as quickly as possible but people 
still want to (seemingly endlessly) tinker with 3.x. Once 3.x I would like to 
announce that 2.x’s EOL is directly tied to the longevity of Java 8. Once Java 
8 falls below 10% usage it will be EOL’d.  So I would rather everyone focus 
their energy on 3.x and not make any more changes to 2.x other than bug-fixes.

FWIW - this is about the 10th time I have said this. Every time people seem to 
agree but then we get the next “why can’t we add this or change this in 2.x”. 
2.x is baked and done as far as I am concerned. To be honest I am almost at the 
point of vetoing every commit for 2.x that isn’t a bug fix.

To be clear, due to Java 8 support it was perfectly fine to leave Log4j 2.x as 
automatic modules.

Ralph

Re: Why is JNDI still necessary?

[Christian Grobmeier]

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 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 dependencies as possible. 

 I understand, Jpms support was added to 2.x recently. Can we do the same thing 
for 2.x?

> So when Log4Shell hit we 
> moved all the JNDI stuff out of log4j-core AND require a property to be 
> set to use it even if you include the jar containing the JNDI support. 
> In addition, JNDI can now only access the java protocol or no protocol. 
>  So yes, it is very safe now.

In this case we need to improve our communication a lot. The main website is 
still showing all cves and I didn’t find the information easily that I just 
asked for.
As you mentioned, this issue is history for three years but the website still 
looks like all hell is loose.

I believe you it is safe (always did after all the countless reviews), but 
people still don’t.

With all that said splitting the repos for2.x still feels right. 

Christian



> Ralph
>
>> On Nov 1, 2023, at 12:22 PM, Christian Grobmeier  
>> wrote:
>> 
>> 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 time?
>> 
>> It always comes up why I don’t recommend some competition instead.
>> 
>> 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.
>> 
>> If we think we have to maintain it, ok, but why can’t we extract it to its 
>> own dependency?
>> 
>> Btw, re your comment on -1: I do not plan to do anything against consensus. 
>> Actually I seek consensus and try to understand better why we still have 
>> this stuff and what we can do to improve perception . In general I feel the 
>> atmosphere in this project has heated up more than it should.
>> 
>> 
>> On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote:
>>> 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 dependencies to explicitly opt in to using the feature (plus 
>>> the JNDI stuff has an additional property you have to set to enable it, 
>>> so you can’t end up with JNDI integration by accident even if the 
>>> dependency is available). That seems fairly safe to me, and the 
>>> naysayers at that point tend to be the same people who prefer 
>>> printf-logging or using C because they’re elite programmers who never 
>>> make mistakes and always design things perfectly decades ahead of time.
>>> 
 On Nov 1, 2023, at 7:18 AM, Apache  wrote:
 
 
 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 so one really needs to 
 view this vote in the light that any component receiving a -1 vote cannot 
 be removed as it will simply get a -1 when the PR/commit is attempted from 
 whomever gave the -1 vote. In other words, this is NOT a procedural vote 
 but a code modification vote that is taking place before the code is 
 modified.
 
 Ralph
 
> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  
> wrote:
> 
> 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 distinguish the various components from each other 
>> without JNDI.
> 
> I understand that in the EJB world you would need JNDI, but I fail to 
> understand how your EJBs would use Log4j JNDI features? It appears to me 
> that while EE world needs it, the Logging world does not necessary need it
> 
>> 
>> Ralph
>> 
>>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
>>> Piotr, I think it is important to differentiate what is a requirement 
>>> and
>>> what is just another way of achieving something. My employer has seve

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

[Piotr P. Karwasz]

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'.
> >
> > We can format all dates the same way `FixedDateFormat` does: we let
> > any date formatter to format the date part once a day and we format
> > the time part ourselves.
>
> Are we doing this now? If not, why not? The only trick is to ensure the date 
> gets formatted on or before the date rollover.

Yes and no. If the user specifies one of a finite set of formats in
`FixedDateFormat.FixedFormat`, then we only format the date part once
a day.
If the user chooses another format, then we fall back on the Commons
Lang `FastDateFormat`.

> One other thing though - don’t we allow different layouts to use different 
> date formats? We would need to ensure every layout is doing this.

Different layouts format dates differently. E.g. PatternLayout uses
the patterns from the original `SimpleDateFormat`, while
JsonTemplateLayout uses the patterns from Java 8 `DateTimeFormatter`.
Under the hood they use `FixedDateFormat` if they can. We actually
have the unification of datetime formatting as one of our milestones.

Piotr

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

[Ralph Goers]

> 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 need to *"parse"* it fast too?
> 
> No we don't. In Commons Lang the parser and formatter  are bound
> together, that is why we have a parser.
> 
> 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'.
> 
> We can format all dates the same way `FixedDateFormat` does: we let
> any date formatter to format the date part once a day and we format
> the time part ourselves.

Are we doing this now? If not, why not? The only trick is to ensure the date 
gets formatted on or before the date rollover. 

One other thing though - don’t we allow different layouts to use different date 
formats? We would need to ensure every layout is doing this.

Ralph

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

[Piotr P. Karwasz]

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 parser and formatter  are bound
together, that is why we have a parser.

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'.

We can format all dates the same way `FixedDateFormat` does: we let
any date formatter to format the date part once a day and we format
the time part ourselves.

Piotr

Re: [Log4j] Main website page

[Ralph Goers]

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/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 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: Why is JNDI still necessary?

[Ralph Goers]

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 dependencies as 
possible. So when Log4Shell hit we moved all the JNDI stuff out of log4j-core 
AND require a property to be set to use it even if you include the jar 
containing the JNDI support. In addition, JNDI can now only access the java 
protocol or no protocol.  So yes, it is very safe now.

Ralph

> On Nov 1, 2023, at 12:22 PM, Christian Grobmeier  wrote:
> 
> 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 time?
> 
> It always comes up why I don’t recommend some competition instead.
> 
> 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.
> 
> If we think we have to maintain it, ok, but why can’t we extract it to its 
> own dependency?
> 
> Btw, re your comment on -1: I do not plan to do anything against consensus. 
> Actually I seek consensus and try to understand better why we still have this 
> stuff and what we can do to improve perception . In general I feel the 
> atmosphere in this project has heated up more than it should.
> 
> 
> On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote:
>> 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 dependencies to explicitly opt in to using the feature (plus 
>> the JNDI stuff has an additional property you have to set to enable it, 
>> so you can’t end up with JNDI integration by accident even if the 
>> dependency is available). That seems fairly safe to me, and the 
>> naysayers at that point tend to be the same people who prefer 
>> printf-logging or using C because they’re elite programmers who never 
>> make mistakes and always design things perfectly decades ahead of time.
>> 
>>> On Nov 1, 2023, at 7:18 AM, Apache  wrote:
>>> 
>>> 
>>> 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 so one really needs to view 
>>> this vote in the light that any component receiving a -1 vote cannot be 
>>> removed as it will simply get a -1 when the PR/commit is attempted from 
>>> whomever gave the -1 vote. In other words, this is NOT a procedural vote 
>>> but a code modification vote that is taking place before the code is 
>>> modified.
>>> 
>>> Ralph
>>> 
 On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  
 wrote:
 
 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 distinguish the various components from each other 
> without JNDI.
 
 I understand that in the EJB world you would need JNDI, but I fail to 
 understand how your EJBs would use Log4j JNDI features? It appears to me 
 that while EE world needs it, the Logging world does not necessary need it
 
> 
> Ralph
> 
>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
>> Piotr, I think it is important to differentiate what is a requirement and
>> what is just another way of achieving something. My employer has several
>> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have 
>> a
>> single JNDI usage I know of.
>> I would like to hear "the functional need" that can't be done in a JEE
>> application without JNDI. My emphasis is important, since "using JNDI" is
>> not a functional need.
>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
>> 
>> wrote:
>>> Hi Christian,
>>> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
>>> wrote:
 I am surprised we still have JNDI in the code at all, but this made me
>>> curious:
 why do JEE users need JNDI features for logging? Why can't they just 
 use
>>> the normal log mechanism?
>>> JNDI is basically a bean container/factory that allows Java EE

Re: [Log4j] Main website page

[Matt Sicker]

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 5:23 PM Ralph Goers 
> wrote:
> 
>> 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: Why is JNDI still necessary?

[Matt Sicker]

> 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, most of the non-core functionality 
was removed from the core jar. JNDI support is offloaded into its own dedicated 
jar, and besides that, you still need to specify a system property to enable 
it. I still think there’s more that can be done in core to remove other 
dependencies, but it’s already at the point where it only (or almost only) 
requires the java.base module (while still bundling some optional things that 
should be split out).

To answer your other question, this makes it its own dependency. I’m not sure 
if any other modules besides the JMX GUI are being split into their own 
dedicated git repositories, but 3.x has significantly split up the bloat of 
optional plugins into their own modules.

Re: [Log4j] Main website page

[Volkan Yazıcı]

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 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.
>
>

Staging is back

[Christian Grobmeier]

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. New is the blog section that we 
can use to communicate with our users. Also includes an rss feed

--
The Apache Software Foundation
V.P., Data Privacy

Re: Why is JNDI still necessary?

[Christian Grobmeier]

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 time?

It always comes up why I don’t recommend some competition instead.

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.

If we think we have to maintain it, ok, but why can’t we extract it to its own 
dependency?

Btw, re your comment on -1: I do not plan to do anything against consensus. 
Actually I seek consensus and try to understand better why we still have this 
stuff and what we can do to improve perception . In general I feel the 
atmosphere in this project has heated up more than it should.


On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote:
> 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 dependencies to explicitly opt in to using the feature (plus 
> the JNDI stuff has an additional property you have to set to enable it, 
> so you can’t end up with JNDI integration by accident even if the 
> dependency is available). That seems fairly safe to me, and the 
> naysayers at that point tend to be the same people who prefer 
> printf-logging or using C because they’re elite programmers who never 
> make mistakes and always design things perfectly decades ahead of time.
>
>> On Nov 1, 2023, at 7:18 AM, Apache  wrote:
>> 
>> 
>> 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 so one really needs to view this 
>> vote in the light that any component receiving a -1 vote cannot be removed 
>> as it will simply get a -1 when the PR/commit is attempted from whomever 
>> gave the -1 vote. In other words, this is NOT a procedural vote but a code 
>> modification vote that is taking place before the code is modified.
>> 
>> Ralph
>> 
>>> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  
>>> wrote:
>>> 
>>> 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 distinguish the various components from each other 
 without JNDI.
>>> 
>>> I understand that in the EJB world you would need JNDI, but I fail to 
>>> understand how your EJBs would use Log4j JNDI features? It appears to me 
>>> that while EE world needs it, the Logging world does not necessary need it
>>> 
 
 Ralph
 
> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
> Piotr, I think it is important to differentiate what is a requirement and
> what is just another way of achieving something. My employer has several
> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
> single JNDI usage I know of.
> I would like to hear "the functional need" that can't be done in a JEE
> application without JNDI. My emphasis is important, since "using JNDI" is
> not a functional need.
> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
> 
> wrote:
>> Hi Christian,
>> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
>> wrote:
>>> I am surprised we still have JNDI in the code at all, but this made me
>> curious:
>>> why do JEE users need JNDI features for logging? Why can't they just use
>> the normal log mechanism?
>> JNDI is basically a bean container/factory that allows Java EE
>> applications to retrieve database connection pools, message queues or
>> mail sessions (and remote code as a bonus).
>> For the JMS appender, JNDI is essential.
>> For the JDBC appender there is an alternative: DBCP2 can provide a
>> database connection pool via a special connection string.
>> The SMTP appender does not use JNDI as far as I remember.
>> Of course there is an alternative to JNDI also in the Java EE world
>> (CDI), but it doesn't work with simple servlet containers like Tomcat.
>> Piotr
>>

Re: Why is JNDI still necessary?

[Matt Sicker]

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 dependencies to 
explicitly opt in to using the feature (plus the JNDI stuff has an additional 
property you have to set to enable it, so you can’t end up with JNDI 
integration by accident even if the dependency is available). That seems fairly 
safe to me, and the naysayers at that point tend to be the same people who 
prefer printf-logging or using C because they’re elite programmers who never 
make mistakes and always design things perfectly decades ahead of time.

> On Nov 1, 2023, at 7:18 AM, Apache  wrote:
> 
> 
> 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 so one really needs to view this 
> vote in the light that any component receiving a -1 vote cannot be removed as 
> it will simply get a -1 when the PR/commit is attempted from whomever gave 
> the -1 vote. In other words, this is NOT a procedural vote but a code 
> modification vote that is taking place before the code is modified.
> 
> Ralph
> 
>> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  wrote:
>> 
>> 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 distinguish the various components from each other 
>>> without JNDI.
>> 
>> I understand that in the EJB world you would need JNDI, but I fail to 
>> understand how your EJBs would use Log4j JNDI features? It appears to me 
>> that while EE world needs it, the Logging world does not necessary need it
>> 
>>> 
>>> Ralph
>>> 
 On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
 Piotr, I think it is important to differentiate what is a requirement and
 what is just another way of achieving something. My employer has several
 Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
 single JNDI usage I know of.
 I would like to hear "the functional need" that can't be done in a JEE
 application without JNDI. My emphasis is important, since "using JNDI" is
 not a functional need.
 On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
 wrote:
> Hi Christian,
> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
> wrote:
>> I am surprised we still have JNDI in the code at all, but this made me
> curious:
>> why do JEE users need JNDI features for logging? Why can't they just use
> the normal log mechanism?
> JNDI is basically a bean container/factory that allows Java EE
> applications to retrieve database connection pools, message queues or
> mail sessions (and remote code as a bonus).
> For the JMS appender, JNDI is essential.
> For the JDBC appender there is an alternative: DBCP2 can provide a
> database connection pool via a special connection string.
> The SMTP appender does not use JNDI as far as I remember.
> Of course there is an alternative to JNDI also in the Java EE world
> (CDI), but it doesn't work with simple servlet containers like Tomcat.
> Piotr
> 

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

[Matt Sicker]

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 `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
> , though it needs
> several assumptions to hold to be effective.
> 
> 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?
> 
> [1] FDP was borrowed from Apache Commons Lang in 2015. I have checked the
> most recent version
> ,
> they still use `getZoneStrings()`.

Re: [Log4j] Main website page

[Ralph Goers]

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

[Ralph Goers]

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, 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ı  wrote:
> 
>> 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
>>   quantify if appropriate
>>   - *Dormant:* not much happening on the code, but at least 3 PMC members
>>   ready to engage if needed
>>   - *At risk:* not enough active PMC members, or a significant number of
>>   contributors left the project, etc.
>>   - *Considering moving to the Attic:* a project that's about to move to
>>   the Attic, or discussing that
>> 
>> IMO, Log4net can be classified as "at risk", right?
>> 

[Log4j] Main website page

[Volkan Yazıcı]

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 Gregory]

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ı  wrote:

> 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
>quantify if appropriate
>- *Dormant:* not much happening on the code, but at least 3 PMC members
>ready to engage if needed
>- *At risk:* not enough active PMC members, or a significant number of
>contributors left the project, etc.
>- *Considering moving to the Attic:* a project that's about to move to
>the Attic, or discussing that
>
> IMO, Log4net can be classified as "at risk", right?
>

Re: Why is JNDI still necessary?

[Apache]


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 so one really needs to view this 
vote in the light that any component receiving a -1 vote cannot be removed as 
it will simply get a -1 when the PR/commit is attempted from whomever gave the 
-1 vote. In other words, this is NOT a procedural vote but a code modification 
vote that is taking place before the code is modified.

Ralph

> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  wrote:
> 
> 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 distinguish the various components from each other 
>> without JNDI.
> 
> I understand that in the EJB world you would need JNDI, but I fail to 
> understand how your EJBs would use Log4j JNDI features? It appears to me that 
> while EE world needs it, the Logging world does not necessary need it
> 
>> 
>> Ralph
>> 
>>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
>>> Piotr, I think it is important to differentiate what is a requirement and
>>> what is just another way of achieving something. My employer has several
>>> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
>>> single JNDI usage I know of.
>>> I would like to hear "the functional need" that can't be done in a JEE
>>> application without JNDI. My emphasis is important, since "using JNDI" is
>>> not a functional need.
>>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
>>> wrote:
 Hi Christian,
 On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
 wrote:
> I am surprised we still have JNDI in the code at all, but this made me
 curious:
> why do JEE users need JNDI features for logging? Why can't they just use
 the normal log mechanism?
 JNDI is basically a bean container/factory that allows Java EE
 applications to retrieve database connection pools, message queues or
 mail sessions (and remote code as a bonus).
 For the JMS appender, JNDI is essential.
 For the JDBC appender there is an alternative: DBCP2 can provide a
 database connection pool via a special connection string.
 The SMTP appender does not use JNDI as far as I remember.
 Of course there is an alternative to JNDI also in the Java EE world
 (CDI), but it doesn't work with simple servlet containers like Tomcat.
 Piotr

[log4net] Project state

[Volkan Yazıcı]

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
   quantify if appropriate
   - *Dormant:* not much happening on the code, but at least 3 PMC members
   ready to engage if needed
   - *At risk:* not enough active PMC members, or a significant number of
   contributors left the project, etc.
   - *Considering moving to the Attic:* a project that's about to move to
   the Attic, or discussing that

IMO, Log4net can be classified as "at risk", right?

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

[Volkan Yazıcı]

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
, though it needs
several assumptions to hold to be effective.

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?

[1] FDP was borrowed from Apache Commons Lang in 2015. I have checked the
most recent version
,
they still use `getZoneStrings()`.

Re: Why is JNDI still necessary?

[Christian Grobmeier]

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 distinguish the various components from each other 
> without JNDI.

I understand that in the EJB world you would need JNDI, but I fail to 
understand how your EJBs would use Log4j JNDI features? It appears to me that 
while EE world needs it, the Logging world does not necessary need it

>
> Ralph
>
>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
>> 
>> Piotr, I think it is important to differentiate what is a requirement and
>> what is just another way of achieving something. My employer has several
>> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
>> single JNDI usage I know of.
>> 
>> I would like to hear "the functional need" that can't be done in a JEE
>> application without JNDI. My emphasis is important, since "using JNDI" is
>> not a functional need.
>> 
>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
>> wrote:
>> 
>>> Hi Christian,
>>> 
>>> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
>>> wrote:
 I am surprised we still have JNDI in the code at all, but this made me
>>> curious:
 why do JEE users need JNDI features for logging? Why can't they just use
>>> the normal log mechanism?
>>> 
>>> JNDI is basically a bean container/factory that allows Java EE
>>> applications to retrieve database connection pools, message queues or
>>> mail sessions (and remote code as a bonus).
>>> For the JMS appender, JNDI is essential.
>>> For the JDBC appender there is an alternative: DBCP2 can provide a
>>> database connection pool via a special connection string.
>>> The SMTP appender does not use JNDI as far as I remember.
>>> 
>>> Of course there is an alternative to JNDI also in the Java EE world
>>> (CDI), but it doesn't work with simple servlet containers like Tomcat.
>>> 
>>> Piotr
>>>

Re: Why is JNDI still necessary?

[Christian Grobmeier]

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 compatible with JNDI and the other JavaEE tech 
> that came in between (the resource loader API thing). Typically, a 
> JavaEE application server (think like JBoss/Wildfly, WebSphere, 
> Weblogic, etc.) would be configured with shared resources like database 
> and JMS connection pools, and those would be obtainable via JNDI. A 
> single application server could host multiple servlets or more advanced 
> packaging formats. All this JNDI usage, however, relies on the Java 
> provider, not the LDAP or DNS or similar providers, so it works without 
> networking being involved.
>
> Do note, though, that there are ways to use this same tech without 
> JNDI, but that typically involves being part of some JavaEE lifecycle, 
> using CDI for dependency injection, etc.

Yes, I am aware of that, being a JNDI user myself back in the days.
My question is not general about JNDI, but why is it necessary in the context 
of Logging?

Piotr already mentioned JMS connections, so is this the only thing or am I 
missing something else?

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

[Christian Grobmeier]

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. This is about adding a deprecated label to 2.x 
components and schedule them for removal in 3.x. That why I quickly give my +1, 
because 3.x is still in alpha, and we can step back from this decision if 
needed.

> Gary is strongly against doing that.
>
> If you are somehow equating deprecation with moving to a separate repo 
> then you are voting on the wrong thing. This vote is basically on what 
> will be removed and no longer supported in 3.x.

No I am voting on the right thing. I am suggesting we are doing a separate vote 
to move out all JNDI related components to their own repo. I am aware Gary is 
opposed to this, but I am strongly in favor to such a move.

Reading my message, I see where this confusion comes from; sorry for that. I 
should have made my two points more clear.

Anyway, still voting +1 on deprecation for now

>
> Ralph
>
>> On Oct 31, 2023, at 2:00 PM, Christian Grobmeier  
>> wrote:
>> 
>> +1 to all - deprecation to me means we add a label that we plan to remove it 
>> in 3.x, but we are not removing it not. We can step back.
>> 
>> Many of those modules don't look as if they need to belong in the main repo. 
>> I can accept kubernetes/docker stuff, but not in the main repo.
>> 
>> I have a strong +1 on removing all JNDI features immediately, making them 
>> available for those poor souls in a separate repo. I opened another thread 
>> where I asked why we need this at all because it seems pointless to me. JNDI 
>> is also a hazardous word within this project.
>> 
>> About the rest I don't have strong feelings
>> 
>> On Mon, Oct 30, 2023, at 09:44, 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`:
>>> * CouchDB appender:
>>> * `log4j-docker`
>>> * GELF appender:
>>> * Kafka appender:
>>> * `log4j-kubernetes`:
>>> * JeroMQ appender:
>>> * JNDI-related features:
>>> * `log4j-jpa`:
>>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> * `log4j-mongodb3`:
>>> * `log4j-spring-boot`:
>>> * Java EE SMTP appender:
>>> * Jakarta EE SMTP appender:
>>> * `log4j-taglib`:
>>> 
>>> Please cast votes for each module/feature separately on this mailing list:
>>> 
>>> [ ] +1,  drop the artifact/module,
>>> [ ] +/-0
>>> [ ] -1,  keep the artifact/module, because...
>>> 
>>> This vote is open for 168 hours (i.e. one week) and each deprecation
>>> will pass unless getting a net negative vote count. All votes are
>>> welcome, but only the Logging Services PMC votes are officially
>>> counted.
>>> 
>>> Piotr