Re: Deterministic formatter

[Piotr P. Karwasz]

Hi Matt,

On Fri, 3 Nov 2023 at 19:44, Matt Sicker  wrote:
>
> Alright, after looking at the differences, I’m strongly in favor of the 
> Palantir version. The differences in how it handles lambdas solves one of the 
> main complaints I ever had about the Google version.

The only disadvantage of the Palantir version is that it does not
provide/support an Eclipse plugin:
https://github.com/palantir/palantir-java-format/issues/833

The code for Eclipse is still there, it just isn't published anywhere
(AFAIK): 
https://github.com/palantir/palantir-java-format/tree/develop/eclipse_plugin

Gary, would it be a big inconvenience using Palantir instead of the
Google AOSP format?

Piotr

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

[Piotr P. Karwasz]

Hi Ralph,

On Sun, 5 Nov 2023 at 05:39, Ralph Goers  wrote:
> If we have changes in 2.x that are not in 3.x they aren’t many and we will 
> never find that out without releasing. In general users don’t want to use 
> alphas or betas. The alphas and betas are there so we can get feedback on 
> issues such as these but the majority of them won’t appear until a GA 
> release. To be clear, we MUST have one or two betas before a GA release 
> precisely because we WILL have issues to deal with. This is completely normal 
> and expected.

Looking at the commit pattern, changes to 2.x are not immediately
followed by changes to 3.x. This does not mean they are neve applied,
but it is hard to check if they were ever applied.

The easiest way to check for regressions is `git diff -w` as Matt
says, but this only makes sense after we reformat the code using a
deterministic formatter.

> Lack integration tests? Yes 2.x lacks integration tests and always has. Why 
> would we delay 3.x for something 2.x doesn’t have. All the integration tests 
> will prove is that various log4j modules can coexist together because some of 
> them use different dependencies. The unit tests are what matter and they by 
> and large pass. That said, I did make the request to create integration tests 
> because Gary has always been afraid of breaking Log4j into multiple repos 
> because he believes having everything compile and build together provides 
> assurance that everything will work together. If everything was using managed 
> depdendencies that would be true. But they don’t so it isn’t.

It's true, 2.x does not have integration tests or better, most unit
tests are in fact integration tests (they test the entire stack). The
tests are performed on the classpath, which is enough for 2.x.

However, the main feature of 3.x is JPMS. We can not possibly test
JPMS with tests that run on the classpath or in the same module as the
code being tested. We need real integration tests that use the module
path and test each optional dependency at a time.

Remark: I am against releasing 3.x in its current state, but I am
flexible on the amount of features required to release it. I second
Christian's proposal for a meeting on November 12th: if the PMC agrees
on a set of tasks required to release 3.x, I might convince my
employer to allow me to implement them as part of my job.

Piotr

[VOTE][LAZY] Release Apache Logging Parent 10.3.0 (RC2)

[Volkan Yazıcı]

This is a lazy-vote to release the Apache Logging Parent 10.3.0 RC2.

Website: https://logging.staged.apache.org/logging-parent
GitHub: https://github.com/apache/logging-parent
Commit: ca99077f82923a97d79ea7947e05cb589873d241
Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1221
Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

=== Release Notes

This minor release contains several small improvements.

 Added

* Add support to extend the `bnd-maven-plugin` configuration with
`bnd-extra-config` property (apache/logging-log4j2#1895)
* Add support to replace `project.build.outputTimestamp` Maven
property in CI (#50)
* Add XSLT transformation step to add a deterministic `serialNumber`
and VDR links to the SBOM
* Add support for an optional `spotbugs-exclude.xml` file in each repo.

 Changed

* `deploy-release-reusable.yaml` is improved to automatically derive
deployed artifacts as attachments. This renders both
`distribution-attachment-filepath-pattern` and
`distribution-attachment-count` input arguments redundant for almost
all cases.
* Disable the usage of `` and alpha releases
in the `bnd-baseline-maven-plugin`.
* Convert `bnd-maven-plugin` API leakage warnings to errors
(apache/logging-log4j2#1895)
* Update `com.google.errorprone:error_prone_core` to version `2.23.0` (#49)
* Update `org.cyclonedx:cyclonedx-maven-plugin` to version `2.7.10` (#54)

 Fixed

* Fix broken changelog entry validation
* Attach `flatten:clean` to `clean` phase
* Add missing `Implementation-` and `Specification-` entries in
`MANIFEST.MF` to `bnd-maven-plugin` configuration
(apache/logging-log4j2#1923)

Re: Deterministic formatter

[Gary Gregory]

Well, I use Eclipse, so... I won't be using whatever this does or when it
does it.

Gary

On Mon, Nov 6, 2023, 3:00 AM Piotr P. Karwasz 
wrote:

> Hi Matt,
>
> On Fri, 3 Nov 2023 at 19:44, Matt Sicker  wrote:
> >
> > Alright, after looking at the differences, I’m strongly in favor of the
> Palantir version. The differences in how it handles lambdas solves one of
> the main complaints I ever had about the Google version.
>
> The only disadvantage of the Palantir version is that it does not
> provide/support an Eclipse plugin:
> https://github.com/palantir/palantir-java-format/issues/833
>
> The code for Eclipse is still there, it just isn't published anywhere
> (AFAIK):
> https://github.com/palantir/palantir-java-format/tree/develop/eclipse_plugin
>
> Gary, would it be a big inconvenience using Palantir instead of the
> Google AOSP format?
>
> Piotr
>

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

[Gary Gregory]

It seems like a good idea to keep releasing alpha-beta-milestones (whatever
we want to call these) for pre-3.0 for now. TBH, I've not even tried it in
my work projects yet. I'd rather do that on a very recent alpha. It feels
like our alpha1 is "old".

Gary

On Mon, Nov 6, 2023, 4:37 AM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers 
> wrote:
> > If we have changes in 2.x that are not in 3.x they aren’t many and we
> will never find that out without releasing. In general users don’t want to
> use alphas or betas. The alphas and betas are there so we can get feedback
> on issues such as these but the majority of them won’t appear until a GA
> release. To be clear, we MUST have one or two betas before a GA release
> precisely because we WILL have issues to deal with. This is completely
> normal and expected.
>
> Looking at the commit pattern, changes to 2.x are not immediately
> followed by changes to 3.x. This does not mean they are neve applied,
> but it is hard to check if they were ever applied.
>
> The easiest way to check for regressions is `git diff -w` as Matt
> says, but this only makes sense after we reformat the code using a
> deterministic formatter.
>
> > Lack integration tests? Yes 2.x lacks integration tests and always has.
> Why would we delay 3.x for something 2.x doesn’t have. All the integration
> tests will prove is that various log4j modules can coexist together because
> some of them use different dependencies. The unit tests are what matter and
> they by and large pass. That said, I did make the request to create
> integration tests because Gary has always been afraid of breaking Log4j
> into multiple repos because he believes having everything compile and build
> together provides assurance that everything will work together. If
> everything was using managed depdendencies that would be true. But they
> don’t so it isn’t.
>
> It's true, 2.x does not have integration tests or better, most unit
> tests are in fact integration tests (they test the entire stack). The
> tests are performed on the classpath, which is enough for 2.x.
>
> However, the main feature of 3.x is JPMS. We can not possibly test
> JPMS with tests that run on the classpath or in the same module as the
> code being tested. We need real integration tests that use the module
> path and test each optional dependency at a time.
>
> Remark: I am against releasing 3.x in its current state, but I am
> flexible on the amount of features required to release it. I second
> Christian's proposal for a meeting on November 12th: if the PMC agrees
> on a set of tasks required to release 3.x, I might convince my
> employer to allow me to implement them as part of my job.
>
> Piotr
>

Re: Deterministic formatter

[Piotr P. Karwasz]

Hi Gary,

On Mon, 6 Nov 2023 at 11:45, Gary Gregory  wrote:
>
> Well, I use Eclipse, so... I won't be using whatever this does or when it
> does it.

What version of Eclipse do you use? The Eclipse plugin is one class, I
can probably fix it, compile it and release it.

Piotr

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

[Ralph Goers]

> On Nov 6, 2023, at 2:37 AM, Piotr P. Karwasz  wrote:
> 
> Hi Ralph,
> 
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers  wrote:
>> If we have changes in 2.x that are not in 3.x they aren’t many and we will 
>> never find that out without releasing. In general users don’t want to use 
>> alphas or betas. The alphas and betas are there so we can get feedback on 
>> issues such as these but the majority of them won’t appear until a GA 
>> release. To be clear, we MUST have one or two betas before a GA release 
>> precisely because we WILL have issues to deal with. This is completely 
>> normal and expected.
> 
> Looking at the commit pattern, changes to 2.x are not immediately
> followed by changes to 3.x. This does not mean they are neve applied,
> but it is hard to check if they were ever applied.

I would disagree. Over the course of the last 5 years I would say that 
committing to both has been the pattern when required at least 90% of the time.

> 
> The easiest way to check for regressions is `git diff -w` as Matt
> says, but this only makes sense after we reformat the code using a
> deterministic formatter.

Well, this has been brought up for the last 2 years. Basic attempts have been 
made to validate it but I have the sense no one is ever going to be 100% 
confident. Personally, I don’t need to be. The few cases we miss will be caught 
fairly quickly once the software is being used. Fixing them shouldn’t be very 
hard.

> 
>> Lack integration tests? Yes 2.x lacks integration tests and always has. Why 
>> would we delay 3.x for something 2.x doesn’t have. All the integration tests 
>> will prove is that various log4j modules can coexist together because some 
>> of them use different dependencies. The unit tests are what matter and they 
>> by and large pass. That said, I did make the request to create integration 
>> tests because Gary has always been afraid of breaking Log4j into multiple 
>> repos because he believes having everything compile and build together 
>> provides assurance that everything will work together. If everything was 
>> using managed depdendencies that would be true. But they don’t so it isn’t.
> 
> It's true, 2.x does not have integration tests or better, most unit
> tests are in fact integration tests (they test the entire stack). The
> tests are performed on the classpath, which is enough for 2.x.
> 
> However, the main feature of 3.x is JPMS. We can not possibly test
> JPMS with tests that run on the classpath or in the same module as the
> code being tested. We need real integration tests that use the module
> path and test each optional dependency at a time.

I don’t disagree that real integration tests should be developed. I just don’t 
see a need to wait for them before a GA release. 

> 
> Remark: I am against releasing 3.x in its current state, but I am
> flexible on the amount of features required to release it. I second
> Christian's proposal for a meeting on November 12th: if the PMC agrees
> on a set of tasks required to release 3.x, I might convince my
> employer to allow me to implement them as part of my job.

I am against a GA release in its current state. Everyone is. But we have to 
keep creating releases to get feedback. Personally, I don’t think we need too 
many more to feel confident.

I am fine with meeting on Nov 12. But the set of tasks I have in mind are a) no 
new features are required b) fix whatever bugs are reported c) test it 
ourselves.  Everything else is optional.

FWIW, I am on step c right now except Log4j isn’t the problem. I am trying to 
upgrade to Spring 3 with Log4j 3 and the Spring upgrade isn’t simple.

Ralph

Re: Deterministic formatter

[Gary Gregory]

The latest: 4.29.0

Gary


On Mon, Nov 6, 2023, 6:55 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Mon, 6 Nov 2023 at 11:45, Gary Gregory  wrote:
> >
> > Well, I use Eclipse, so... I won't be using whatever this does or when it
> > does it.
>
> What version of Eclipse do you use? The Eclipse plugin is one class, I
> can probably fix it, compile it and release it.
>
> Piotr
>

Re: Deterministic formatter

[Carter Kozak]

I'd be happy to review+release changes to get the eclipse plugin in that repo 
into a good place as long as it doesn't make the build process a great deal 
more complicated. We don't have many folks internally using eclipse so support 
hasn't been a priority, but the easier it is to use across common toolchains, 
the better!

-ck

On Mon, Nov 6, 2023, at 06:55, Piotr P. Karwasz wrote:
> Hi Gary,
> 
> On Mon, 6 Nov 2023 at 11:45, Gary Gregory  wrote:
> >
> > Well, I use Eclipse, so... I won't be using whatever this does or when it
> > does it.
> 
> What version of Eclipse do you use? The Eclipse plugin is one class, I
> can probably fix it, compile it and release it.
> 
> Piotr
> 

[log4j] Security page refactoring

[Volkan Yazıcı]

I have created #1948 
refactoring the Log4j security page. See the PR description for details.
Reviews are welcome.

[log4j] What is JPMS support and its state

[Volkan Yazıcı]

Could somebody help me to understand what we mean by JPMS support, please?
Because I have the impression that people think `2.x` does not have JPMS
support and `main` excels at it.

`2.21.0` brought `2.x` a fully-fledged JPMS support. JPMS and OSGi
descriptors are auto-generated by `bnd-maven-plugin`. Piotr and I manually
marked every single package that needs to be exported and checked every
single generated `module-info.java` and `MANIFEST.MF`. IIRC, 3+ users
shared positive feedback in GitHub Issues and the next `2.x` release will
even support `jlink` due to #1896. Since there are no `module-info.java`
files lying around (`bnd-maven-plugin` adds them to the JAR at the
`package` phase), IDEs are not confused by the module-vs-class path dilemma
too.

OTOH, JPMS support in the `main` branch was first established by
hand-written `module-info.java` files and then later on reimplemented (work
in progress!) by Piotr via porting stuff from `2.x`. Nobody has tested it
yet, AFAIK. `jlink` is known to not work there.

In the context of JPMS support, `2.x` is a clear winner over `3.x`, AFAIC.
If not, I would appreciate your help in explaining what I am missing.

Though `3.x` is good at two things regarding modularization:

   1. It breaks down `log4j-core` into more fine-grained modules (e.g.,
   `log4j-csv`)
   2. It has slightly improved package encapsulation. That is, some
   internal classes are indeed moved to internal packages.

`2.x` can never implement #2, since it is a breaking change. Thought #1 can
very well be implemented for `2.x` – users will just need to add a new JAR
to their classpath.

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

[Piotr P. Karwasz]

Hi all,

On Mon, 30 Oct 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...

The following PMC have expressed their votes: Gary Gregory, Christian
Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.

The PMC decided to deprecate the following modules/features in 2.x and
to remove them in 3.x:
 * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
 * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
 * `log4j-jpa` (binding +1 from grobmeier, vy and me),
 * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
rgoers, vy and me),
 * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
 * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
mattsicker, rgoers, vy and me),
 * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and me),

Piotr

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

[Volkan Yazıcı]

this doesnt capture the account right for json and yaml layout. Gary only
wants to keep the xml layout:
https://lists.apache.org/thread/qdf5zrtqg294zj9voj6x7rlhsfln752p

On Mon, 6 Nov 2023 at 22:52, Piotr P. Karwasz 
wrote:

> Hi all,
>
> On Mon, 30 Oct 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...
>
> The following PMC have expressed their votes: Gary Gregory, Christian
> Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.
>
> The PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
>  * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy
> and me),
>  * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and
> me),
>  * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
>  * `log4j-jpa` (binding +1 from grobmeier, vy and me),
>  * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
> rgoers, vy and me),
>  * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
>  * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),
>  * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and
> me),
>
> Piotr
>

Re: [log4j] What is JPMS support and its state

[Ralph Goers]

You know, I almost didn’t want to answer this email because after reading the 
text it was quite obvious to me that the question you are really trying to ask 
is:
“What more needs to be done to kill off 3.x?”  That being said I will still 
answer your question.

First, I will say that the work to create module-info files in 2.x wouldn’t 
have been possible without all the effort put in to figure out how to separate 
the tests from the code. You have absolutely no idea how many hours I put in 
trying various permutations and asking around.

Second, providing a module-info.class does not, in and of itself, make a 
library JPMS compliant. That is a requirement for it to be a named module, but 
it is only one facet of JPMS.

Ask yourself, why was JPMS created? To allow Oracle to keep its JDK developers 
busy? No. The JDK had become bloated and even a simple HelloWorld app required 
the whole thing. Likewise, for a library like Log4j to depend on anything 
besides java.base will force the application to be bloated.
Consider this (decompiled by IntelliJ - I am not really sure why none of them 
are listed as optional).:

requires com.fasterxml.jackson.annotation;
requires com.fasterxml.jackson.core;
requires com.fasterxml.jackson.databind;
requires com.fasterxml.jackson.dataformat.xml;
requires com.fasterxml.jackson.dataformat.yaml;
requires com.lmax.disruptor;
requires disruptor;
requires java.activation;
requires java.base;
requires java.compiler;
requires java.desktop;
requires java.logging;
requires java.management;
requires java.naming;
requires java.rmi;
requires java.scripting;
requires java.sql;
requires java.xml;
requires javax.jms.api;
requires javax.mail.api;
requires jeromq;
requires kafka.clients;
requires org.apache.commons.compress;
requires org.apache.commons.csv;
requires org.apache.logging.log4j;
requires org.codehaus.stax2;
requires org.fusesource.jansi;
requires org.jctools.core;
requires org.osgi.core;


With this:
// Required Dependencies
requires transitive org.apache.logging.log4j;
requires transitive org.apache.logging.log4j.plugins;
// Optional Dependencies
requires static java.desktop;
requires static java.management;
requires static java.sql;
requires static java.rmi;
requires static java.xml;
requires static com.lmax.disruptor;
requires static org.jctools.core;
requires static org.osgi.framework;
requires static com.conversantmedia.disruptor;
requires static com.fasterxml.jackson.core;
requires static com.fasterxml.jackson.databind;
requires static com.fasterxml.jackson.dataformat.xml;
requires static com.fasterxml.jackson.dataformat.yaml;
requires static org.apache.commons.compress;
requires static org.fusesource.jansi;

And even this list for 3.x is larger than we would like. I believe it has been 
identified how to eliminate all the java.* dependencies, but I would be 
surprised if even more of the non-java dependencies can be extracted.
A lot of this was gained by splitting the modules in 3.x, which you admitted 
cannot be done in 2.x. Since that is one of the primary benefits of JPMS I am 
not sure how that makes 2.x better.

Yes, we had to generate the module-info.java files by hand. Why? Because 
tooling didn’t exist. If it does now great1 But I am not sure why you are 
calling that out as if it is a negative thing. I mean, you still had to create 
the list of dependencies in the pom.xml by hand. What really is the difference?

Next, there is a good chance that users really using JPMS won’t be able to 
access any plugins outside of log4j-core. See 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String).
 This is precisely why 3.x uses ServiceLoader to locate all plugins.

So, while you may have successfully create module-info.class files was that a 
good thing? As an automatic module the rules in getResource() don’t apply.

Next, Java supports ModuleLayers. See 
https://stackoverflow.com/questions/61195909/what-is-the-relation-between-modulelayer-and-classloader.
 If you get nothing out of this other than “it is complicated” that is enough. 
The bottom line here is again that you can’t rely on ClassLoader.getResource() 
to find plugins.

As you may or may not have noticed, annotation processors cannot be located on 
the module path and must be strictly declared. In 2.x the processor is always 
included inside log4j-core. In 3.x it is simpler as it is its own module. Not 
necessarily a big deal but it provides better encapsulation.

So is 2.x really the “clear winner”? I don’t think so, at least as far as JPMS 
is concerned.  You haven’t even touched on the other benefits of 3.x .

And the above hasn’t even touched on the other improvements in 3.x that are 
listed at https://logging.apache.org/log4j/3.x/, which unfortunately doesn’t 
call out the DI system Matt created (yet). 

Ralph





> On Nov 6, 2023, at 2:02 PM, Volkan Yazıcı  wrote:
> 
> Could somebody help me to understand what we mean by JPMS support, please

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

[Ralph Goers]

I also voted +1 on log4j-spring-boot. 

Ralph

> On Nov 6, 2023, at 2:51 PM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> On Mon, 30 Oct 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...
> 
> The following PMC have expressed their votes: Gary Gregory, Christian
> Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me.
> 
> The PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
> * `log4j-cassandra` (binding +1 from grobmeier, mattsicker, rgoers, vy and 
> me),
> * CouchDB appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * GELF appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * Kafka appender (binding +1 from grobmeier, mattsicker, rgoers, vy and me),
> * jeroMQ appender (binding +1 from grobmeier, mattsicker, vy and me),
> * `log4j-jpa` (binding +1 from grobmeier, vy and me),
> * `log4j-mongodb3` (binding +1 from ggregory, grobmeier, mattsicker,
> rgoers, vy and me),
> * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
> * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),
> * `log4j-taglib` (binding +1 from ggregory, grobmeier, mattsicker, vy and me),
> 
> Piotr

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

[Piotr P. Karwasz]

Hi,

On Mon, 6 Nov 2023 at 22:51, Piotr P. Karwasz  wrote:
>  * `log4j-spring-boot` (binding +1 from ggregory, grobmeier, vy and me),
>  * Java EE SMTP appender (binding +1 from ggregory, grobmeier,
> mattsicker, rgoers, vy and me),

Sorry, I inverted the list of voters here: for `log4j-spring-boot`
everybody voted +1 (ggregory, grobmeier, mattsicker, rgoers, vy and
me). For the Java EE SMTP appender the only +1 are from ggregory,
grobmeier, vy and me.

Piotr