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

[Piotr P. Karwasz]

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

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

[Piotr P. Karwasz]

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

I agree that 3.x should have a fixed number of features. We should
probably agree on them and close the list.

There are things that I would like to add to 3.x, that you won't allow
me to do in a minor release:
 * drop JMX support in 3.0.x: I have a basic understanding on how
Micrometer works. In 3.1.x I could restore the monitoring capabilities
of Log4j Core with a `log4j-core-jmx` module and possibly a
`log4j-core-micrometer` module (or `micrometer-log4j-core` if the
Micrometer project accepts such a contribution). This could probably
be done by just extending the public `log4j-core` API,
 * move the code that depends on LMAX disruptor to a separate module
(`log4j-async-logger`, but I am open to suggestions for a better
name),
 * move the code that depends on Conversant disruptor to a separate
module (`log4j-async-queue-disruptor` for lack of a better name),
 * move the code that depends on JCTools to a separate module
(`log4j-async-queue-jctools`); the same applies to JTL,
 * move the code that depends on Commons Compress to a separate module
(`log4j-file-compress`),
 * move the code that depends on JAnsi to a separate module
(`log4j-console-jansi`),
 * remove the Jackson-based configuration factories (to be restored in
3.1.x) or move them to a different module,
 * remove the `log4j-jndi` dependency from `log4j-jdbc` by creating
`log4j-jdbc-jndi`.
 * drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is
not supported any more by Ceki; I know this contains some support for
structured events from `slf4j-ext` 1.7.25 that is not present in
`log4j-slfj42-impl`, but I suppose this is no longer needed.

There are some changes we are waiting for
(https://github.com/apache/logging-log4j2/milestone/2):
 * LoggerContext-scoped properties, plugins, etc. I am not sure we can
introduce this in a minor release. I recently extended JCL to use the
Log4j API and SLF4J and noticed that Logback does not allow multiple
logger contexts. We do, but those are useless if Log4j Core in the
system classloader can't pick up plugins from other classloaders. A
little example: in Tomcat the system classloader basically contains
only the logging framework and `log4j-core` can not pick up
`log4j-web` in the classloader with all the Servlet API classes,
 * Recycler API: I doubt we can introduce a uniform way to cache
objects without breaking changes. Volkan will pick this up shortly, so
be patient,
 * regressions, regressions and once again regressions. One is even
reported (https://github.com/apache/logging-log4j2/issues/1439) and
has been sitting there for some time.

Piotr

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

[Apache]

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.x release. The 
same is generally true for your other bullets as well.

The point of alphas and betas is to find regressions. We need to fix them.

Ralph

> On Nov 2, 2023, at 1:17 AM, Piotr P. Karwasz  wrote:
> 
> 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 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.
> 
> I agree that 3.x should have a fixed number of features. We should
> probably agree on them and close the list.
> 
> There are things that I would like to add to 3.x, that you won't allow
> me to do in a minor release:
> * drop JMX support in 3.0.x: I have a basic understanding on how
> Micrometer works. In 3.1.x I could restore the monitoring capabilities
> of Log4j Core with a `log4j-core-jmx` module and possibly a
> `log4j-core-micrometer` module (or `micrometer-log4j-core` if the
> Micrometer project accepts such a contribution). This could probably
> be done by just extending the public `log4j-core` API,
> * move the code that depends on LMAX disruptor to a separate module
> (`log4j-async-logger`, but I am open to suggestions for a better
> name),
> * move the code that depends on Conversant disruptor to a separate
> module (`log4j-async-queue-disruptor` for lack of a better name),
> * move the code that depends on JCTools to a separate module
> (`log4j-async-queue-jctools`); the same applies to JTL,
> * move the code that depends on Commons Compress to a separate module
> (`log4j-file-compress`),
> * move the code that depends on JAnsi to a separate module
> (`log4j-console-jansi`),
> * remove the Jackson-based configuration factories (to be restored in
> 3.1.x) or move them to a different module,
> * remove the `log4j-jndi` dependency from `log4j-jdbc` by creating
> `log4j-jdbc-jndi`.
> * drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is
> not supported any more by Ceki; I know this contains some support for
> structured events from `slf4j-ext` 1.7.25 that is not present in
> `log4j-slfj42-impl`, but I suppose this is no longer needed.
> 
> There are some changes we are waiting for
> (https://github.com/apache/logging-log4j2/milestone/2):
> * LoggerContext-scoped properties, plugins, etc. I am not sure we can
> introduce this in a minor release. I recently extended JCL to use the
> Log4j API and SLF4J and noticed that Logback does not allow multiple
> logger contexts. We do, but those are useless if Log4j Core in the
> system classloader can't pick up plugins from other classloaders. A
> little example: in Tomcat the system classloader basically contains
> only the logging framework and `log4j-core` can not pick up
> `log4j-web` in the classloader with all the Servlet API classes,
> * Recycler API: I doubt we can introduce a uniform way to cache
> objects without breaking changes. Volkan will pick this up shortly, so
> be patient,
> * regressions, regressions and once again regressions. One is even
> reported (https://github.com/apache/logging-log4j2/issues/1439) and
> has been sitting there for some time.
> 
> Piotr

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

[Volkan Yazıcı]

*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
`log4j-core` and make sure every `Instant` formatting is performed via that.


On Thu, Nov 2, 2023 at 12:27 AM Piotr P. Karwasz 
wrote:

> 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: Features for 3.x was: Why is JNDI still necessary?

[Piotr P. Karwasz]

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 but unless it can be done quickly I’d rather do it in a future 3.x 
> release. The same is generally true for your other bullets as well.

What I meant: we can not **remove** anything after 3.0.0 GA is
released, this includes module refactorings.
I know that you are pushing hard to have a beta by the end of this
year and GA shortly after.

The problem is: the development of 3.x has been stagnating since June.
Since then I have only seen Matt, Volkan and myself committing
something.
Since most of these changes can not be done in our day jobs, a more
realistic release date for 3.x is the end of the year 2024.
Right now the JLink project I added to Samples works with 2.x, but
**fails** with 3.x (besides, 3.x snapshots are not getting published
since a month and I don't have the faintest idea why).

Piotr

Re: [log4net] Project state

[Davyd McColl]

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 Wed, Nov 1, 2023 at 1:20 PM Davyd McColl  wrote:

Hi

Yes, I'd agree that log4net is "at risk" seeing as I'm apparently
the only active maintainer - and I'm not even that active, having
not found time in quite a while to do some log4net work ):


-d

On 2023/11/01 13:47, 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?

[Christian Grobmeier]

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

So far, 3.x is super slow and as Piotr pointed out, a release might happen by 
the end of 2024. we then still have many users on 2.x who will hesitate to 
migrate to 3.x until it is battlefield proven. It will take years to eol 2.x

I don’t think 2.x will eol together with j8. Actually I see something different 
for 2.x when it comes to jdks. Not proposing anything this is just a feeling.

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

This is disappointing to hear you consider your voting power to move things to 
your liking. If you start doing something like this, I am out. Not that it 
matters much, I assume. Reach consensus first.

We had that behavior before, don’t move down this path. You have plenty of 
components that you want help with too. You don’t want these kind of veto 
threats.

So far we are adding up new components while we struggle to maintain the old 
ones. Some of us are concerned that the immense line of code we overlook are 
too much to handle. Some of us also see that 2.x will stay a long time because 
of this fact.

Retire components or move them out the main build, we can safe time that is 
well invested in 3.x, Flume or Audit.

Sorry you have to repeat yourself. I see others repeat themselves too.





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

Re: Java version usage

[Gary Gregory]

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, 2023, 1:20 AM Ralph Goers  wrote:

> 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: Features for 3.x was: Why is JNDI still necessary?

[Ralph Goers]

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 always be 
fine other oving things if they are no longer supportable or need to be 
separated into a new module so long as end user code doesn’t have to be changed.

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.

Ralph

> On Nov 2, 2023, at 2: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 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.x release. The same is generally true for your other bullets as 
>> well.
> 
> What I meant: we can not **remove** anything after 3.0.0 GA is
> released, this includes module refactorings.
> I know that you are pushing hard to have a beta by the end of this
> year and GA shortly after.
> 
> The problem is: the development of 3.x has been stagnating since June.
> Since then I have only seen Matt, Volkan and myself committing
> something.
> Since most of these changes can not be done in our day jobs, a more
> realistic release date for 3.x is the end of the year 2024.
> Right now the JLink project I added to Samples works with 2.x, but
> **fails** with 3.x (besides, 3.x snapshots are not getting published
> since a month and I don't have the faintest idea why).
> 
> Piotr

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

[Ralph Goers]

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  wrote:
> 
> 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 
> always be fine other oving things if they are no longer supportable or need 
> to be separated into a new module so long as end user code doesn’t have to be 
> changed.
> 
> 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.
> 
> Ralph
> 
>> On Nov 2, 2023, at 2: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 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.x release. The same is generally true for your other bullets as 
>>> well.
>> 
>> What I meant: we can not **remove** anything after 3.0.0 GA is
>> released, this includes module refactorings.
>> I know that you are pushing hard to have a beta by the end of this
>> year and GA shortly after.
>> 
>> The problem is: the development of 3.x has been stagnating since June.
>> Since then I have only seen Matt, Volkan and myself committing
>> something.
>> Since most of these changes can not be done in our day jobs, a more
>> realistic release date for 3.x is the end of the year 2024.
>> Right now the JLink project I added to Samples works with 2.x, but
>> **fails** with 3.x (besides, 3.x snapshots are not getting published
>> since a month and I don't have the faintest idea why).
>> 
>> Piotr

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

[Gary Gregory]

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 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 
> wrote:
> >
> > 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 always be fine other oving things if they are no longer supportable or
> need to be separated into a new module so long as end user code doesn’t
> have to be changed.
> >
> > 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.
> >
> > Ralph
> >
> >> On Nov 2, 2023, at 2: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 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.x release. The same is generally true for your other bullets as
> well.
> >>
> >> What I meant: we can not **remove** anything after 3.0.0 GA is
> >> released, this includes module refactorings.
> >> I know that you are pushing hard to have a beta by the end of this
> >> year and GA shortly after.
> >>
> >> The problem is: the development of 3.x has been stagnating since June.
> >> Since then I have only seen Matt, Volkan and myself committing
> >> something.
> >> Since most of these changes can not be done in our day jobs, a more
> >> realistic release date for 3.x is the end of the year 2024.
> >> Right now the JLink project I added to Samples works with 2.x, but
> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
> >> since a month and I don't have the faintest idea why).
> >>
> >> Piotr
>
>

Re: Why is JNDI still necessary?

[Gary Gregory]

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 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 <
> grobme...@apache.org> 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
> >>
> >>>

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

[Gary Gregory]

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 looked for a while.

>  * CouchDB appended:
-0: Prefer keeping since there is no official JDBC access that I know
of but I have not looked for a while.

>  * `log4j-docker`
-1 Docker seems too important.

>  * GELF appended:
+0

>  * Kafka appended:
-0: Prefer keeping since there is no official JMS access that I know
of but I have not looked for a while.

>  * `log4j-kubernetes`:
-1: This should match what we do with Docker.

>  * JeroMQ appender:
-0: Prefer keeping since there is no official JMS access that I know
of but I have not looked for a while.

>  * JNDI-related features:
-1: Needed in enterprise environments, OK to split out in a separate
Maven module.

>  * `log4j-jpa`:
-0: JDBC Appender is good enough for me. Use-case seems narrow except
for a JPA shop.

>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
-1: I want the ability to log to XML (narrow use-case, sure, but handy).

>  * `log4j-mongodb3`:
+1: I use mongodb4

>  * `log4j-spring-boot`:
-1: Spring seems too important.

>  * Java EE SMTP appended:
+1: Use the Jakarta version.

>  * Jakarta EE SMTP appended:
-1: Handy, sometimes.

>  * `log4j-taglib`:
+1, never used it.

Gary

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

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

[Ralph Goers]

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-boot should NOT 
be included. Since Log4j 3.x (at least in my mind) goes hand in hand with 
Spring Boot 3 then removing log4j-spring-boot in 3.x makes sense.

Ralph

> On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> 
> 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 looked for a while.
> 
>> * CouchDB appended:
> -0: Prefer keeping since there is no official JDBC access that I know
> of but I have not looked for a while.
> 
>> * `log4j-docker`
> -1 Docker seems too important.
> 
>> * GELF appended:
> +0
> 
>> * Kafka appended:
> -0: Prefer keeping since there is no official JMS access that I know
> of but I have not looked for a while.
> 
>> * `log4j-kubernetes`:
> -1: This should match what we do with Docker.
> 
>> * JeroMQ appender:
> -0: Prefer keeping since there is no official JMS access that I know
> of but I have not looked for a while.
> 
>> * JNDI-related features:
> -1: Needed in enterprise environments, OK to split out in a separate
> Maven module.
> 
>> * `log4j-jpa`:
> -0: JDBC Appender is good enough for me. Use-case seems narrow except
> for a JPA shop.
> 
>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> -1: I want the ability to log to XML (narrow use-case, sure, but handy).
> 
>> * `log4j-mongodb3`:
> +1: I use mongodb4
> 
>> * `log4j-spring-boot`:
> -1: Spring seems too important.
> 
>> * Java EE SMTP appended:
> +1: Use the Jakarta version.
> 
>> * Jakarta EE SMTP appended:
> -1: Handy, sometimes.
> 
>> * `log4j-taglib`:
> +1, never used it.
> 
> Gary
> 
>> 
>> 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

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

[Piotr P. Karwasz]

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 or JAXB appender in a couple of hours.

> >  * `log4j-spring-boot`:
> -1: Spring seems too important.

Are you sure you want to _veto_ a module removal based on a feeling?
`log4j-spring-boot` has 4 elements: a lookup, a property source, an
arbiter and an improved version of `Log4j2LoggingSystem`.
All these elements were submitted to Spring Boot by Ralph and included in 3.x.
So this module targets the users that don't want Spring Boot 3.x, but
want Log4j 3.x.

Piotr

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

[Volkan Yazıcı]

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 package. *Objections?*

[1] To be precise, in `org.apache.logging.log4j.core.util.datetime`
package, some methods from `FastDateFormat` and `Format`, and
`FastDateParser[Test]` classes. That is, touched to 4 files in total.

On Thu, Nov 2, 2023 at 10:00 AM Volkan Yazıcı  wrote:

> *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
> `log4j-core` and make sure every `Instant` formatting is performed via that.
>
>
> On Thu, Nov 2, 2023 at 12:27 AM Piotr P. Karwasz 
> wrote:
>
>> 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: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary D. Gregory]

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? Jackson is optimized for JSON, we
> can easily write a SAX, StAX or JAXB appender in a couple of hours.

That was not the question asked by this VOTE. Also, smells or NIH and "famous 
last words" ;-)

> 
> > >  * `log4j-spring-boot`:
> > -1: Spring seems too important.
> 
> Are you sure you want to _veto_ a module removal based on a feeling?
> `log4j-spring-boot` has 4 elements: a lookup, a property source, an
> arbiter and an improved version of `Log4j2LoggingSystem`.
> All these elements were submitted to Spring Boot by Ralph and included in 3.x.
> So this module targets the users that don't want Spring Boot 3.x, but
> want Log4j 3.x.

I feel it is too big an ask to force people to migrate to 3.x which is not 
released.

I also feel ALL of this is premature until 3.x is out.

Gary

> 
> Piotr
> 

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

[Volkan Yazıcı]

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


Gary, do you only want to keep `XmlLayout` or all 3?

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

[Ralph Goers]

+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 dates (ugh!) to
> Commons Lang. The API is identical, they simply need to use a
> separate package. *Objections?*
> 
> [1] To be precise, in `org.apache.logging.log4j.core.util.datetime`
> package, some methods from `FastDateFormat` and `Format`, and
> `FastDateParser[Test]` classes. That is, touched to 4 files in total.
> 

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

[Piotr P. Karwasz]

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 based on a feeling?
> > `log4j-spring-boot` has 4 elements: a lookup, a property source, an
> > arbiter and an improved version of `Log4j2LoggingSystem`.
> > All these elements were submitted to Spring Boot by Ralph and included in 
> > 3.x.
> > So this module targets the users that don't want Spring Boot 3.x, but
> > want Log4j 3.x.
>
> I feel it is too big an ask to force people to migrate to 3.x which is not 
> released.

I am not sure I am following. You don't want to force Log4j 3.x users
to migrate to Spring Boot 3.x?
I think the pressure to migrate to Spring Boot 3.x will be higher than
the pressure to migrate to Log4j 3.x.

Piotr

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

[Ralph Goers]

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  wrote:
> 
> 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 based on a feeling?
>>> `log4j-spring-boot` has 4 elements: a lookup, a property source, an
>>> arbiter and an improved version of `Log4j2LoggingSystem`.
>>> All these elements were submitted to Spring Boot by Ralph and included in 
>>> 3.x.
>>> So this module targets the users that don't want Spring Boot 3.x, but
>>> want Log4j 3.x.
>> 
>> I feel it is too big an ask to force people to migrate to 3.x which is not 
>> released.
> 
> I am not sure I am following. You don't want to force Log4j 3.x users
> to migrate to Spring Boot 3.x?
> I think the pressure to migrate to Spring Boot 3.x will be higher than
> the pressure to migrate to Log4j 3.x.
> 
> Piotr

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

[Ralph Goers]

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 generalized to handle all 3, but that may be asking too 
much.

Ralph

> On Nov 2, 2023, at 8:43 AM, Volkan Yazıcı  wrote:
> 
> 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).
> 
> 
> Gary, do you only want to keep `XmlLayout` or all 3?

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

[Piotr P. Karwasz]

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
> Commons Lang. The API is identical, they simply need to use a
> separate package. *Objections?*

I have mixed feelings about that. Technically it is a breaking change
in the API, since the package was never considered as private.

On the other hand the alternative would be to either to remove the
`parser` field in `FastDateFormat` and change all the `parse` methods
to throw an exception or to rewire everything to use `FastDatePrinter`
instead of `FastDateFormat`.

Piotr

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

[Christian Grobmeier]

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

If this is the case, then how would we achieve the goal of releasing it 
together?

With flume, audit and the other stuff eating time, it will be hard to get this 
done.

This workload is too much for this handful of people. Removing load was btw 
also the idea of retiring components, so we can spend this time on other things 
of interest

I would like to suggest that we have a team call soon where we collect our 
ideas of how we can reach that and refresh our shared vision.

Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring 
framework is 6.x.


>>
>> Ralph
>>
>> > On Nov 2, 2023, at 3:53 AM, Ralph Goers 
>> wrote:
>> >
>> > 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 always be fine other oving things if they are no longer supportable or
>> need to be separated into a new module so long as end user code doesn’t
>> have to be changed.
>> >
>> > 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.
>> >
>> > Ralph
>> >
>> >> On Nov 2, 2023, at 2: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 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.x release. The same is generally true for your other bullets as
>> well.
>> >>
>> >> What I meant: we can not **remove** anything after 3.0.0 GA is
>> >> released, this includes module refactorings.
>> >> I know that you are pushing hard to have a beta by the end of this
>> >> year and GA shortly after.
>> >>
>> >> The problem is: the development of 3.x has been stagnating since June.
>> >> Since then I have only seen Matt, Volkan and myself committing
>> >> something.
>> >> Since most of these changes can not be done in our day jobs, a more
>> >> realistic release date for 3.x is the end of the year 2024.
>> >> Right now the JLink project I added to Samples works with 2.x, but
>> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
>> >> since a month and I don't have the faintest idea why).
>> >>
>> >> Piotr
>>
>>

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

[Piotr P. Karwasz]

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 big imperfection! ;-)

Piotr

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

[Matt Sicker]

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:
+1 deprecate
> * Kafka appender:
+1 deprecate
> * `log4j-kubernetes`:
-0
> * JeroMQ appender:
+1 deprecate
> * JNDI-related features:
-0, would only deprecate if we deprecate the things that require it, too
> * `log4j-jpa`:
+0, sort of seems redundant with the JDBC plugins, but I’m not super familiar
> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
+1 deprecate
> * `log4j-mongodb3`:
+1 deprecate, this version of mongo is ancient
> * `log4j-spring-boot`:
+1 deprecate, Spring Boot 3 has better built-in support for this already
> * Java EE SMTP appender:
-0, all programs eventually learn how to send email, but it’s the old package 
name
> * Jakarta EE SMTP appender:
-1, all programs eventually learn how to send email, current API
> * `log4j-taglib`:
+1 deprecate

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

[Matt Sicker]

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 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 generalized to handle all 3, but that may be asking too 
> much.
> 
> Ralph
> 
>> On Nov 2, 2023, at 8:43 AM, Volkan Yazıcı  wrote:
>> 
>> 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).
>> 
>> 
>> Gary, do you only want to keep `XmlLayout` or all 3?
> 

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

[Volkan Yazıcı]

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

.

I ask for your understanding and forgiveness, Piotr. 🙇

On Thu, Nov 2, 2023 at 6:14 PM Piotr P. Karwasz 
wrote:

> 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
> > Commons Lang. The API is identical, they simply need to use a
> > separate package. *Objections?*
>
> I have mixed feelings about that. Technically it is a breaking change
> in the API, since the package was never considered as private.
>
> On the other hand the alternative would be to either to remove the
> `parser` field in `FastDateFormat` and change all the `parse` methods
> to throw an exception or to rewire everything to use `FastDatePrinter`
> instead of `FastDateFormat`.
>
> Piotr
>

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

[Matt Sicker]

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 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.x release. The same is generally true for your other bullets as 
>> well.
> 
> What I meant: we can not **remove** anything after 3.0.0 GA is
> released, this includes module refactorings.
> I know that you are pushing hard to have a beta by the end of this
> year and GA shortly after.
> 
> The problem is: the development of 3.x has been stagnating since June.
> Since then I have only seen Matt, Volkan and myself committing
> something.
> Since most of these changes can not be done in our day jobs, a more
> realistic release date for 3.x is the end of the year 2024.
> Right now the JLink project I added to Samples works with 2.x, but
> **fails** with 3.x (besides, 3.x snapshots are not getting published
> since a month and I don't have the faintest idea why).
> 
> Piotr

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

[Piotr P. Karwasz]

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

Can you also cherry-pick it to `main`?

Piotr

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

[Ralph Goers]

> 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 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 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.
> 
> If this is the case, then how would we achieve the goal of releasing it 
> together?

Releasing what together? Spring Boot 3 is already GA. It is using Log4j 2.x 
currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring Boot 3 
requires Java 17) it will be a better choice for most users. I would also not 
be surprised to see Spring Boot update their dependencies to use Log4j 3.x at 
some point since they won’t require any code changes.

> 
> With flume, audit and the other stuff eating time, it will be hard to get 
> this done.

Get what done? As far as I am concerned Log4j 3.x can go to beta now and GA the 
first of the year. There are no required features left, just stuff that would 
be nice to get done but can be done after the initial GA release.

> 
> This workload is too much for this handful of people. Removing load was btw 
> also the idea of retiring components, so we can spend this time on other 
> things of interest

Again, I don’t know to what workload you are referring.

> 
> I would like to suggest that we have a team call soon where we collect our 
> ideas of how we can reach that and refresh our shared vision.

I’m pretty much always up for a team call.

> 
> Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring 
> framework is 6.x.

Spring Boot 3.x

Ralph