Project activity monitor

[Volkan Yazıcı]

I have set up a page sharing statistics about all Logging Services
projects: https://logging-activity-monitor.staged.apache.org/ There you can
find activity data collected from GitHub repositories for all projects:
Log4j, Chainsaw, Log4Net, Log4cxx, etc.

Since the `logging-site` repository is pretty much broken at this point, I
am waiting for Christian's cue to push this to production.

Note that the data is updated monthly by CI

and
displayed using a single HTML+JS blob
.
Hence, no vendor lock-in (except sql-js) or INFRA dependency.

Re: Project activity monitor

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 31 Oct 2023 at 12:07, Volkan Yazıcı  wrote:
>
> I have set up a page sharing statistics about all Logging Services
> projects: https://logging-activity-monitor.staged.apache.org/ There you can
> find activity data collected from GitHub repositories for all projects:
> Log4j, Chainsaw, Log4Net, Log4cxx, etc.

Very nice, could you add all non-archived projects to the mix?
I am thinking about `logging-server`.

Piotr

Re: Project activity monitor

[Volkan Yazıcı]

I can, but I prefer you doing it. It is good for sharing the know-how. (Let
me know if you want me to do it.)

   1. Add `log4j-server` entry to the `proj-spec` matrix in
   `update-stats.yaml`
   

   2. Manually run the workflow on `asf-staging` branch (Click on the `Run
   workflow` button Actions tab
   
   )


On Tue, Oct 31, 2023 at 12:21 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 31 Oct 2023 at 12:07, Volkan Yazıcı  wrote:
> >
> > I have set up a page sharing statistics about all Logging Services
> > projects: https://logging-activity-monitor.staged.apache.org/ There you
> can
> > find activity data collected from GitHub repositories for all projects:
> > Log4j, Chainsaw, Log4Net, Log4cxx, etc.
>
> Very nice, could you add all non-archived projects to the mix?
> I am thinking about `logging-server`.
>
> Piotr
>

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

[Ralph Goers]

Here are my votes:

> On Oct 30, 2023, at 1: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
> * CouchDB appender:
+1
> * `log4j-docker`
-1 - Still useful and supportable
> * GELF appender:
+1 - JsonTemplateLayout replaces this
> * Kafka appender:
+1 (I have mixed feelings about this. It would obviously be useful but the 
version we support is ancient and doesn’t support many things one would want)
> * `log4j-kubernetes`:
-1 Still useful and supportable
> * JeroMQ appender:
+0 I’ve never used JeroMQ.
> * JNDI-related features:
-1 Unfortunately, JEE users require this.
> * `log4j-jpa`:
+0 I’ve never cared about logging to an RDBMS.
> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
+0 (We have no replacement for logging to XML or Yaml although I have no idea 
why one would want tot).
> * `log4j-mongodb3`:
+1
> * `log4j-spring-boot`:
+1 (Spring provides this in Spring 3 and users or that should use Log4j 3.x)
> * Java EE SMTP appender:
+0 
> * Jakarta EE SMTP appender:
+0
> * `log4j-taglib`:
+0 (I never understood the purpose of this).


Ralph

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

Why is JNDI still necessary?

[Christian Grobmeier]

Hi,

on the recent deprecation vote I saw this vote (from Ralph):

> * JNDI-related features:
-1 Unfortunately, JEE users require this.

I am surprised we still have JNDI in the code at all, but this made me curious:
why do JEE users need JNDI features for logging? Why can't they just use the 
normal log mechanism?

To me, JNDI is a burned word in Logging. No matter what we say about it, nobody 
will ever believe we will have this under control.

I am a strong +1 on removing this, even for 2.x. Users can have a separate 
module they can add to their pom, if they really need it. I am aware of 
versioning and this could be considered a breaking change, but after all, the 
APIs are intact, and only the pom changes. 

That being said, I would like to understand better what "jndi related" features 
in our code base are actually solving, because from marketing perspective, they 
are super GAU.

Kind regards,
Christian

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

[Christian Grobmeier]

+1 to all - deprecation to me means we add a label that we plan to remove it in 
3.x, but we are not removing it not. We can step back.

Many of those modules don't look as if they need to belong in the main repo. I 
can accept kubernetes/docker stuff, but not in the main repo.

I have a strong +1 on removing all JNDI features immediately, making them 
available for those poor souls in a separate repo. I opened another thread 
where I asked why we need this at all because it seems pointless to me. JNDI is 
also a hazardous word within this project.

About the rest I don't have strong feelings

On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
> This is a vote to deprecate the following `2.x` modules and features
> and remove them from the `3.x` release:
>
>  * `log4j-cassandra`:
>  * CouchDB appender:
>  * `log4j-docker`
>  * GELF appender:
>  * Kafka appender:
>  * `log4j-kubernetes`:
>  * JeroMQ appender:
>  * JNDI-related features:
>  * `log4j-jpa`:
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>  * `log4j-mongodb3`:
>  * `log4j-spring-boot`:
>  * Java EE SMTP appender:
>  * Jakarta EE SMTP appender:
>  * `log4j-taglib`:
>
> Please cast votes for each module/feature separately on this mailing list:
>
> [ ] +1,  drop the artifact/module,
> [ ] +/-0
> [ ] -1,  keep the artifact/module, because...
>
> This vote is open for 168 hours (i.e. one week) and each deprecation
> will pass unless getting a net negative vote count. All votes are
> welcome, but only the Logging Services PMC votes are officially
> counted.
>
> Piotr

Re: Why is JNDI still necessary?

[Piotr P. Karwasz]

Hi Christian,

On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier  wrote:
> I am surprised we still have JNDI in the code at all, but this made me 
> curious:
> why do JEE users need JNDI features for logging? Why can't they just use the 
> normal log mechanism?

JNDI is basically a bean container/factory that allows Java EE
applications to retrieve database connection pools, message queues or
mail sessions (and remote code as a bonus).
For the JMS appender, JNDI is essential.
For the JDBC appender there is an alternative: DBCP2 can provide a
database connection pool via a special connection string.
The SMTP appender does not use JNDI as far as I remember.

Of course there is an alternative to JNDI also in the Java EE world
(CDI), but it doesn't work with simple servlet containers like Tomcat.

Piotr

Re: Why is JNDI still necessary?

[Volkan Yazıcı]

Piotr, I think it is important to differentiate what is a requirement and
what is just another way of achieving something. My employer has several
Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
single JNDI usage I know of.

I would like to hear "the functional need" that can't be done in a JEE
application without JNDI. My emphasis is important, since "using JNDI" is
not a functional need.

On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
wrote:

> Hi Christian,
>
> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
> wrote:
> > I am surprised we still have JNDI in the code at all, but this made me
> curious:
> > why do JEE users need JNDI features for logging? Why can't they just use
> the normal log mechanism?
>
> JNDI is basically a bean container/factory that allows Java EE
> applications to retrieve database connection pools, message queues or
> mail sessions (and remote code as a bonus).
> For the JMS appender, JNDI is essential.
> For the JDBC appender there is an alternative: DBCP2 can provide a
> database connection pool via a special connection string.
> The SMTP appender does not use JNDI as far as I remember.
>
> Of course there is an alternative to JNDI also in the Java EE world
> (CDI), but it doesn't work with simple servlet containers like Tomcat.
>
> Piotr
>

Re: Why is JNDI still necessary?

[Matt Sicker]

I’m not sure how much people use this deployment model anymore, but JNDI was 
and still is at the core of JavaEE (now JakartaEE) dependency injection APIs. 
While CDI is the current way of using dependency injection there, CDI is 
compatible with JNDI and the other JavaEE tech that came in between (the 
resource loader API thing). Typically, a JavaEE application server (think like 
JBoss/Wildfly, WebSphere, Weblogic, etc.) would be configured with shared 
resources like database and JMS connection pools, and those would be obtainable 
via JNDI. A single application server could host multiple servlets or more 
advanced packaging formats. All this JNDI usage, however, relies on the Java 
provider, not the LDAP or DNS or similar providers, so it works without 
networking being involved.

Do note, though, that there are ways to use this same tech without JNDI, but 
that typically involves being part of some JavaEE lifecycle, using CDI for 
dependency injection, etc.

> On Oct 31, 2023, at 3:57 PM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> on the recent deprecation vote I saw this vote (from Ralph):
> 
>> * JNDI-related features:
> -1 Unfortunately, JEE users require this.
> 
> I am surprised we still have JNDI in the code at all, but this made me 
> curious:
> why do JEE users need JNDI features for logging? Why can't they just use the 
> normal log mechanism?
> 
> To me, JNDI is a burned word in Logging. No matter what we say about it, 
> nobody will ever believe we will have this under control.
> 
> I am a strong +1 on removing this, even for 2.x. Users can have a separate 
> module they can add to their pom, if they really need it. I am aware of 
> versioning and this could be considered a breaking change, but after all, the 
> APIs are intact, and only the pom changes. 
> 
> That being said, I would like to understand better what "jndi related" 
> features in our code base are actually solving, because from marketing 
> perspective, they are super GAU.
> 
> Kind regards,
> Christian

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

[Ralph Goers]

Christian,

Deprecation and moving to separate modules are not the same thing at all. I 
would be +1 to moving everything on this list that isn’t outright removed to 
separate repos. I have stated that several times.  Gary is strongly against 
doing that.

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

Ralph

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

Re: Why is JNDI still necessary?

[Ralph Goers]

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.

Ralph

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

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

[Ralph Goers]

Rats. In my first sentence replace “modules” with “repos”.

Ralph

> On Oct 31, 2023, at 3:53 PM, Ralph Goers  wrote:
> 
> Christian,
> 
> Deprecation and moving to separate modules are not the same thing at all. I 
> would be +1 to moving everything on this list that isn’t outright removed to 
> separate repos. I have stated that several times.  Gary is strongly against 
> doing that.
> 
> If you are somehow equating deprecation with moving to a separate repo then 
> you are voting on the wrong thing. This vote is basically on what will be 
> removed and no longer supported in 3.x.
> 
> Ralph
> 
>> On Oct 31, 2023, at 2:00 PM, Christian Grobmeier  
>> wrote:
>> 
>> +1 to all - deprecation to me means we add a label that we plan to remove it 
>> in 3.x, but we are not removing it not. We can step back.
>> 
>> Many of those modules don't look as if they need to belong in the main repo. 
>> I can accept kubernetes/docker stuff, but not in the main repo.
>> 
>> I have a strong +1 on removing all JNDI features immediately, making them 
>> available for those poor souls in a separate repo. I opened another thread 
>> where I asked why we need this at all because it seems pointless to me. JNDI 
>> is also a hazardous word within this project.
>> 
>> About the rest I don't have strong feelings
>> 
>> On Mon, Oct 30, 2023, at 09:44, Piotr P. Karwasz wrote:
>>> This is a vote to deprecate the following `2.x` modules and features
>>> and remove them from the `3.x` release:
>>> 
>>> * `log4j-cassandra`:
>>> * CouchDB appender:
>>> * `log4j-docker`
>>> * GELF appender:
>>> * Kafka appender:
>>> * `log4j-kubernetes`:
>>> * JeroMQ appender:
>>> * JNDI-related features:
>>> * `log4j-jpa`:
>>> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> * `log4j-mongodb3`:
>>> * `log4j-spring-boot`:
>>> * Java EE SMTP appender:
>>> * Jakarta EE SMTP appender:
>>> * `log4j-taglib`:
>>> 
>>> Please cast votes for each module/feature separately on this mailing list:
>>> 
>>> [ ] +1,  drop the artifact/module,
>>> [ ] +/-0
>>> [ ] -1,  keep the artifact/module, because...
>>> 
>>> This vote is open for 168 hours (i.e. one week) and each deprecation
>>> will pass unless getting a net negative vote count. All votes are
>>> welcome, but only the Logging Services PMC votes are officially
>>> counted.
>>> 
>>> Piotr
>