[log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Matt Sicker <bo...@gmail.com>]

Hey all,

I was wondering if you'd all be on board for 3.x to try and move some
of our 3rd party integration plugins to their respective projects
rather than maintaining them here. For example, all the networked
appender plugins and other plugins that typically require a third
party client library or driver would be more appropriately located
with their respective dependencies. A concrete example would be moving
the Flume appender to Apache Flume once they're finished with 1.10.0
which is under review right now. While we'd keep releasing this
appender in 2.x, come 3.x, we'd be able to point to the official Flume
plugin instead. The same idea could apply to numerous plugins such as:

* Cassandra appender -> Apache Cassandra
* Flume appender -> Apache Flume
* JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
* JMS appender (could go to ActiveMQ or Jakarta)
* Kafka appender -> Apache Kafka
* MongoDB appenders -> MongoDB?
* CouchDB appenders -> Apache CouchDB
* SMTP appender -> makybe Jakarta?
* ZeroMQ appender -> ZeroMQ project?
* Spring integration stuff -> Spring project
* Liquibase binding -> Liquibase

I imagine it makes some sense to continue publishing our -web and
-appserver modules as they're more specific to hooking log4j-core into
those things, but I'm open to other ideas there.

For any plugins we're trying to move, if the upstream projects don't
want them, then those modules get EOL'd and removed for 3.x.

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Matt Sicker <bo...@gmail.com>]

I think the appender API has been stable since 2.0. I do have a backlog item about adding an async API for appenders, but that would be additive.

—
Matt Sicker

> On Jun 7, 2022, at 19:03, Robert Middleton <rm...@apache.org> wrote:
> 
> It seems to me that this would only work if a) there exists a stable
> API/ABI for log4j and b) sufficient demand for the appenders exists.
> If a stable API/ABI doesn't exist, then the new maintainers would be
> on the hook for any changes that log4j made, which seems unreasonable
> to me.
> 
> -Robert Middleton
> 
>> On Tue, Jun 7, 2022 at 2:40 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>> 
>> Hi,
>> 
>>> On Tue, 7 Jun 2022 at 20:17, Matt Sicker <bo...@gmail.com> wrote:
>>> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
>> 
>> I would try EclipseLink, since Hibernate made their choice a long time ago.
>> 
>>> * JMS appender (could go to ActiveMQ or Jakarta)
>> 
>> An in-house collaboration with ActiveMQ seems more realistic.
>> 
>>> * SMTP appender -> makybe Jakarta?
>> 
>> Jakarta Mail has a stable API, we can keep this one.
>> 
>>> For any plugins we're trying to move, if the upstream projects don't
>>> want them, then those modules get EOL'd and removed for 3.x.
>> 
>> I would settle for a list of maintainers from those projects that are
>> willing to help, whenever they decide on breaking an API or to advise
>> which version should be supported and which one can be dropped.
>> 
>> Regarding `log4j-appserver`, the Jetty part is obsolete (does not work
>> with Jetty 10) and the Tomcat part could be migrated to Tomcat. It's
>> only one class, but there is also an old PR of mine that I closed in
>> order not to pollu^wenrich Log4j2 with new external dependencies.
>> 
>> Piotr

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

["Piotr P. Karwasz" <pi...@gmail.com>]

Hi Robert,

On Wed, 8 Jun 2022 at 02:03, Robert Middleton <rm...@apache.org> wrote:
> It seems to me that this would only work if a) there exists a stable
> API/ABI for log4j and b) sufficient demand for the appenders exists.

The main problem is that there is almost no demand for these
appenders. IIRC there are a couple of thousands of downloads monthly
for these appenders. This is 3-4 orders of magnitude less than
`log4j-core`.

Piotr

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Robert Middleton <rm...@apache.org>]

It seems to me that this would only work if a) there exists a stable
API/ABI for log4j and b) sufficient demand for the appenders exists.
If a stable API/ABI doesn't exist, then the new maintainers would be
on the hook for any changes that log4j made, which seems unreasonable
to me.

-Robert Middleton

On Tue, Jun 7, 2022 at 2:40 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi,
>
> On Tue, 7 Jun 2022 at 20:17, Matt Sicker <bo...@gmail.com> wrote:
> > * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
>
> I would try EclipseLink, since Hibernate made their choice a long time ago.
>
> > * JMS appender (could go to ActiveMQ or Jakarta)
>
> An in-house collaboration with ActiveMQ seems more realistic.
>
> > * SMTP appender -> makybe Jakarta?
>
> Jakarta Mail has a stable API, we can keep this one.
>
> > For any plugins we're trying to move, if the upstream projects don't
> > want them, then those modules get EOL'd and removed for 3.x.
>
> I would settle for a list of maintainers from those projects that are
> willing to help, whenever they decide on breaking an API or to advise
> which version should be supported and which one can be dropped.
>
> Regarding `log4j-appserver`, the Jetty part is obsolete (does not work
> with Jetty 10) and the Tomcat part could be migrated to Tomcat. It's
> only one class, but there is also an old PR of mine that I closed in
> order not to pollu^wenrich Log4j2 with new external dependencies.
>
> Piotr

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

["Piotr P. Karwasz" <pi...@gmail.com>]

Hi,

On Tue, 7 Jun 2022 at 20:17, Matt Sicker <bo...@gmail.com> wrote:
> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)

I would try EclipseLink, since Hibernate made their choice a long time ago.

> * JMS appender (could go to ActiveMQ or Jakarta)

An in-house collaboration with ActiveMQ seems more realistic.

> * SMTP appender -> makybe Jakarta?

Jakarta Mail has a stable API, we can keep this one.

> For any plugins we're trying to move, if the upstream projects don't
> want them, then those modules get EOL'd and removed for 3.x.

I would settle for a list of maintainers from those projects that are
willing to help, whenever they decide on breaking an API or to advise
which version should be supported and which one can be dropped.

Regarding `log4j-appserver`, the Jetty part is obsolete (does not work
with Jetty 10) and the Tomcat part could be migrated to Tomcat. It's
only one class, but there is also an old PR of mine that I closed in
order not to pollu^wenrich Log4j2 with new external dependencies.

Piotr

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Matt Sicker <bo...@gmail.com>]

Splitting the repos might be effectively the same as donating them to others, so I’m fine with either approach.

—
Matt Sicker

> On Jun 10, 2022, at 10:43, Ralph Goers <ra...@dslextreme.com> wrote:
> 
> It has been my plan to create a PR for Spring to move the Spring Boot 
> support there. They already provide support for Log4j2, it is just deficient.
> 
> I have no plans to move the Flume Appender to the Flume project. 
> However, I do plan to move it to its own Log4j repo in 3.x. I would 
> suggest the same thing happen to many of these other components.
> 
> Other projects taking ownership of them is very unlikely to happen.
> 
> Ralph
> 
> 
>> On Jun 10, 2022, at 5:51 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>> 
>> Would any of those projects be willing to maintain a Log4j-related
>> component that was born and raised in the Log4j land? I think that is
>> pretty wishful thinking, though feel free to give it a try. I support any
>> initiative that would lower the maintenance burden without hindering the
>> development of Log4j. Does anybody volunteer to raise this subject in the
>> associated mailing lists?
>> 
>> I am not concerned about the `log4j-core` API stability, I think we do a
>> good job there.
>> 
>>> ... if the upstream projects don't want them, then those modules get
>> EOL'd and removed for 3.x
>> 
>> Umm... I don't think that is a nice way to treat our existing users. (Ralph
>> would disagree anyway. In fact, I am surprised he hasn't reacted yet.) I
>> would rather move these to separate repositories and maintain them there.
>> For those interested in this route, please start another thread. For
>> inspiration, see my earlier posts
>> <https://lists.apache.org/thread/8rflqfctmpd79h11o78zkfymtn6g9sds>.
>> 
>> On Tue, Jun 7, 2022 at 8:17 PM Matt Sicker <bo...@gmail.com> wrote:
>> 
>>> Hey all,
>>> 
>>> I was wondering if you'd all be on board for 3.x to try and move some
>>> of our 3rd party integration plugins to their respective projects
>>> rather than maintaining them here. For example, all the networked
>>> appender plugins and other plugins that typically require a third
>>> party client library or driver would be more appropriately located
>>> with their respective dependencies. A concrete example would be moving
>>> the Flume appender to Apache Flume once they're finished with 1.10.0
>>> which is under review right now. While we'd keep releasing this
>>> appender in 2.x, come 3.x, we'd be able to point to the official Flume
>>> plugin instead. The same idea could apply to numerous plugins such as:
>>> 
>>> * Cassandra appender -> Apache Cassandra
>>> * Flume appender -> Apache Flume
>>> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
>>> * JMS appender (could go to ActiveMQ or Jakarta)
>>> * Kafka appender -> Apache Kafka
>>> * MongoDB appenders -> MongoDB?
>>> * CouchDB appenders -> Apache CouchDB
>>> * SMTP appender -> makybe Jakarta?
>>> * ZeroMQ appender -> ZeroMQ project?
>>> * Spring integration stuff -> Spring project
>>> * Liquibase binding -> Liquibase
>>> 
>>> I imagine it makes some sense to continue publishing our -web and
>>> -appserver modules as they're more specific to hooking log4j-core into
>>> those things, but I'm open to other ideas there.
>>> 
>>> For any plugins we're trying to move, if the upstream projects don't
>>> want them, then those modules get EOL'd and removed for 3.x.
>>> 
> 

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Ralph Goers <ra...@dslextreme.com>]

It has been my plan to create a PR for Spring to move the Spring Boot 
support there. They already provide support for Log4j2, it is just deficient.

I have no plans to move the Flume Appender to the Flume project. 
However, I do plan to move it to its own Log4j repo in 3.x. I would 
suggest the same thing happen to many of these other components.

Other projects taking ownership of them is very unlikely to happen.

Ralph


> On Jun 10, 2022, at 5:51 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> Would any of those projects be willing to maintain a Log4j-related
> component that was born and raised in the Log4j land? I think that is
> pretty wishful thinking, though feel free to give it a try. I support any
> initiative that would lower the maintenance burden without hindering the
> development of Log4j. Does anybody volunteer to raise this subject in the
> associated mailing lists?
> 
> I am not concerned about the `log4j-core` API stability, I think we do a
> good job there.
> 
>> ... if the upstream projects don't want them, then those modules get
> EOL'd and removed for 3.x
> 
> Umm... I don't think that is a nice way to treat our existing users. (Ralph
> would disagree anyway. In fact, I am surprised he hasn't reacted yet.) I
> would rather move these to separate repositories and maintain them there.
> For those interested in this route, please start another thread. For
> inspiration, see my earlier posts
> <https://lists.apache.org/thread/8rflqfctmpd79h11o78zkfymtn6g9sds>.
> 
> On Tue, Jun 7, 2022 at 8:17 PM Matt Sicker <bo...@gmail.com> wrote:
> 
>> Hey all,
>> 
>> I was wondering if you'd all be on board for 3.x to try and move some
>> of our 3rd party integration plugins to their respective projects
>> rather than maintaining them here. For example, all the networked
>> appender plugins and other plugins that typically require a third
>> party client library or driver would be more appropriately located
>> with their respective dependencies. A concrete example would be moving
>> the Flume appender to Apache Flume once they're finished with 1.10.0
>> which is under review right now. While we'd keep releasing this
>> appender in 2.x, come 3.x, we'd be able to point to the official Flume
>> plugin instead. The same idea could apply to numerous plugins such as:
>> 
>> * Cassandra appender -> Apache Cassandra
>> * Flume appender -> Apache Flume
>> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
>> * JMS appender (could go to ActiveMQ or Jakarta)
>> * Kafka appender -> Apache Kafka
>> * MongoDB appenders -> MongoDB?
>> * CouchDB appenders -> Apache CouchDB
>> * SMTP appender -> makybe Jakarta?
>> * ZeroMQ appender -> ZeroMQ project?
>> * Spring integration stuff -> Spring project
>> * Liquibase binding -> Liquibase
>> 
>> I imagine it makes some sense to continue publishing our -web and
>> -appserver modules as they're more specific to hooking log4j-core into
>> those things, but I'm open to other ideas there.
>> 
>> For any plugins we're trying to move, if the upstream projects don't
>> want them, then those modules get EOL'd and removed for 3.x.
>> 

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

["Piotr P. Karwasz" <pi...@gmail.com>]

Hi,

On Fri, 10 Jun 2022 at 14:51, Volkan Yazıcı <vo...@yazi.ci> wrote:
> Would any of those projects be willing to maintain a Log4j-related
> component that was born and raised in the Log4j land? I think that is
> pretty wishful thinking, though feel free to give it a try. I support any
> initiative that would lower the maintenance burden without hindering the
> development of Log4j. Does anybody volunteer to raise this subject in the
> associated mailing lists?

I raised the subject on Tomcat's mailing list:
https://lists.apache.org/thread/o0rpd8jmosr6crvnhcj4bl45krtzvrhd

I'll keep you updated on the results.

Piotr

Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?

[Volkan Yazıcı <vo...@yazi.ci>]

Would any of those projects be willing to maintain a Log4j-related
component that was born and raised in the Log4j land? I think that is
pretty wishful thinking, though feel free to give it a try. I support any
initiative that would lower the maintenance burden without hindering the
development of Log4j. Does anybody volunteer to raise this subject in the
associated mailing lists?

I am not concerned about the `log4j-core` API stability, I think we do a
good job there.

> ... if the upstream projects don't want them, then those modules get
EOL'd and removed for 3.x

Umm... I don't think that is a nice way to treat our existing users. (Ralph
would disagree anyway. In fact, I am surprised he hasn't reacted yet.) I
would rather move these to separate repositories and maintain them there.
For those interested in this route, please start another thread. For
inspiration, see my earlier posts
<https://lists.apache.org/thread/8rflqfctmpd79h11o78zkfymtn6g9sds>.

On Tue, Jun 7, 2022 at 8:17 PM Matt Sicker <bo...@gmail.com> wrote:

> Hey all,
>
> I was wondering if you'd all be on board for 3.x to try and move some
> of our 3rd party integration plugins to their respective projects
> rather than maintaining them here. For example, all the networked
> appender plugins and other plugins that typically require a third
> party client library or driver would be more appropriately located
> with their respective dependencies. A concrete example would be moving
> the Flume appender to Apache Flume once they're finished with 1.10.0
> which is under review right now. While we'd keep releasing this
> appender in 2.x, come 3.x, we'd be able to point to the official Flume
> plugin instead. The same idea could apply to numerous plugins such as:
>
> * Cassandra appender -> Apache Cassandra
> * Flume appender -> Apache Flume
> * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?)
> * JMS appender (could go to ActiveMQ or Jakarta)
> * Kafka appender -> Apache Kafka
> * MongoDB appenders -> MongoDB?
> * CouchDB appenders -> Apache CouchDB
> * SMTP appender -> makybe Jakarta?
> * ZeroMQ appender -> ZeroMQ project?
> * Spring integration stuff -> Spring project
> * Liquibase binding -> Liquibase
>
> I imagine it makes some sense to continue publishing our -web and
> -appserver modules as they're more specific to hooking log4j-core into
> those things, but I'm open to other ideas there.
>
> For any plugins we're trying to move, if the upstream projects don't
> want them, then those modules get EOL'd and removed for 3.x.
>