Re: [chainsaw] DB package?

[Christian Grobmeier]

On Tue, Oct 24, 2023, at 22:30, Robert Middleton wrote:
> Those classes are to receive log events from a database table.  Log4j1
> and log4cxx can write log messages directly to a database; I'm not
> sure about log4j2.

Yes, there is a JDBC Appender that is discussed more often these days

> I'm not sure exactly what it does/how it does it, but it's going to
> effectively do something like "SELECT * FROM Logs" and then pass those
> log messages up to other parts of chainsaw.

I see. So the job would be to check how log4j2 appenders works, and then read 
from that database.
Sounds like fun :-)
Not sure if I leave the comment-skeleton or remove and rewrite it from scratch 
yet, but now i got an idea.
Thanks Robert!

Re: [chainsaw] DB package?

[Christian Grobmeier]

On Tue, Oct 24, 2023, at 22:19, Matt Sicker wrote:
> If you use Log4j in Chainsaw, you could set up a JDBC appender or 
> similar to forward things along. The Flume appender could be useful 
> there, too, but that sort of moves the database configuration into your 
> Flume config.

I see - but I understand Chainsaw should be for receiving and analysing mostly, 
right?
So forwarding from Chainsaw seems off to me, that's what Flume should do 
(without Chainsaw)

Re: [chainsaw] DB package?

[Robert Middleton]

Those classes are to receive log events from a database table.  Log4j1
and log4cxx can write log messages directly to a database; I'm not
sure about log4j2.

I'm not sure exactly what it does/how it does it, but it's going to
effectively do something like "SELECT * FROM Logs" and then pass those
log messages up to other parts of chainsaw.

-Robert Middleton

On Tue, Oct 24, 2023 at 4:20 PM Matt Sicker  wrote:
>
> If you use Log4j in Chainsaw, you could set up a JDBC appender or similar to 
> forward things along. The Flume appender could be useful there, too, but that 
> sort of moves the database configuration into your Flume config.
>
> > On Oct 24, 2023, at 3:14 PM, Christian Grobmeier  
> > wrote:
> >
> > Hi,
> >
> > in this package:
> > org.apache.log4j.db
> >
> > all classes are commented. I am tempted to just remove it in full, but I am 
> > not sure what i was supposed to do.
> >
> > Docs read:
> >
> > "Provides means to append logging events into various databases."
> >
> > Does that mean, Chainsaw would collect logs and then send it to databases? 
> > Isn't it what Flume (et al) is expected to do?
> >
> > Kind regards,
> > Christian
>

Re: [chainsaw] DB package?

[Matt Sicker]

If you use Log4j in Chainsaw, you could set up a JDBC appender or similar to 
forward things along. The Flume appender could be useful there, too, but that 
sort of moves the database configuration into your Flume config.

> On Oct 24, 2023, at 3:14 PM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> in this package:
> org.apache.log4j.db
> 
> all classes are commented. I am tempted to just remove it in full, but I am 
> not sure what i was supposed to do.
> 
> Docs read:
> 
> "Provides means to append logging events into various databases."
> 
> Does that mean, Chainsaw would collect logs and then send it to databases? 
> Isn't it what Flume (et al) is expected to do?
> 
> Kind regards,
> Christian

[chainsaw] DB package?

[Christian Grobmeier]

Hi,

in this package:
org.apache.log4j.db

all classes are commented. I am tempted to just remove it in full, but I am not 
sure what i was supposed to do.

Docs read:

"Provides means to append logging events into various databases."

Does that mean, Chainsaw would collect logs and then send it to databases? 
Isn't it what Flume (et al) is expected to do?

Kind regards,
Christian

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary Gregory]

Pin it good! 😉

On Tue, Oct 24, 2023, 2:04 PM Volkan Yazıcı  wrote:

> I'd like to pin this post in case somebody wants to add yet another manual
> step to the release instructions. 😜
>
> On Tue, Oct 24, 2023 at 1:58 PM Piotr P. Karwasz 
> wrote:
>
> > Hi Gary,
> >
> > On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory 
> wrote:
> > >
> > > Odd, I do not even see 2.21.1 on
> >
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
> > >
> > > ?
> >
> > I have forgotten about one step of the release process. ;-)
> >
> > Piotr
> >
>

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Volkan Yazıcı]

I'd like to pin this post in case somebody wants to add yet another manual
step to the release instructions. 😜

On Tue, Oct 24, 2023 at 1:58 PM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory  wrote:
> >
> > Odd, I do not even see 2.21.1 on
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
> >
> > ?
>
> I have forgotten about one step of the release process. ;-)
>
> Piotr
>

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary Gregory]

Ah! ;-)

On Tue, Oct 24, 2023, 7:58 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory  wrote:
> >
> > Odd, I do not even see 2.21.1 on
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
> >
> > ?
>
> I have forgotten about one step of the release process. ;-)
>
> Piotr
>

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Piotr P. Karwasz]

Hi Gary,

On Tue, 24 Oct 2023 at 13:41, Gary D. Gregory  wrote:
>
> Odd, I do not even see 2.21.1 on 
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/
>
> ?

I have forgotten about one step of the release process. ;-)

Piotr

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary D. Gregory]

Odd, I do not even see 2.21.1 on 
https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-api/

?

Gary

On 2023/10/24 11:21:01 "Gary D. Gregory" wrote:
> Please do not announce before the jars show up on 
> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/
> 
> TY!
> Gary
> 
> On 2023/10/24 07:06:12 "Piotr P. Karwasz" wrote:
> > Apache Log4j team is pleased to announce the 2.21.1
> > release. Apache Log4j is a versatile, industrial-strength
> > Java logging framework composed of an API, its implementation,
> > and components to assist the deployment for various use cases.
> > For further information (support, download, etc.) see the project
> > website[1].
> > 
> > [1] https://logging.apache.org/log4j
> > 
> > == Release Notes
> > 
> > This patch release contains only the fix of a `log4j-jcl` bug that
> > prevents it from connecting with `commons-logging`.
> > 
> > The Log4j 2.21.1 API, as well as the other artifacts, maintains binary
> > compatibility with the previous release.
> > 
> > Apache Log4j 2.21.1 requires Java 8 to run.
> > The build requires JDK 11 and generates reproducible binaries.
> > 
> > For complete information on Apache Log4j 2, including instructions on
> > how to submit bug reports, patches, get support, or suggestions for
> > improvement, see the Apache Log4j 2.x website[2].
> > 
> > [2] http://logging.apache.org/log4j/2.x/
> > 
> > === Fixed
> > 
> > * Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865)
> > 
> > Piotr
> > 
> 

Re: [ANNOUNCE] Apache Log4j 2.21.1 released

[Gary D. Gregory]

Please do not announce before the jars show up on 
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/

TY!
Gary

On 2023/10/24 07:06:12 "Piotr P. Karwasz" wrote:
> Apache Log4j team is pleased to announce the 2.21.1
> release. Apache Log4j is a versatile, industrial-strength
> Java logging framework composed of an API, its implementation,
> and components to assist the deployment for various use cases.
> For further information (support, download, etc.) see the project
> website[1].
> 
> [1] https://logging.apache.org/log4j
> 
> == Release Notes
> 
> This patch release contains only the fix of a `log4j-jcl` bug that
> prevents it from connecting with `commons-logging`.
> 
> The Log4j 2.21.1 API, as well as the other artifacts, maintains binary
> compatibility with the previous release.
> 
> Apache Log4j 2.21.1 requires Java 8 to run.
> The build requires JDK 11 and generates reproducible binaries.
> 
> For complete information on Apache Log4j 2, including instructions on
> how to submit bug reports, patches, get support, or suggestions for
> improvement, see the Apache Log4j 2.x website[2].
> 
> [2] http://logging.apache.org/log4j/2.x/
> 
> === Fixed
> 
> * Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865)
> 
> Piotr
> 

Re: [log4j] Project URLs per major version

[Gary Gregory]

Blow up -> become very large, not corrupted.

Gary

On Tue, Oct 24, 2023, 6:45 AM Volkan Yazıcı  wrote:

> Let me elaborate on what I want to achieve with CI automation.
>
> *[I will focus on Log4j, but my statements apply to other Maven-based
> products as well; Log4j Tools, Log4j Kotlin, etc.]*
>
>1. When a new Log4j `release/A.B.C` branch is detected, `logging
>*-log4j-A_B_C.staged*.apache.org` will be automatically populated using
>`./mvnw site`
>2. When a new Log4j release of version `A.B.C` is detected, `
>logging.apache.org*/log4j/A.B.C*` will be automatically populated using
>`./mvnw site`
>3. When a change in `A.x` branch is detected, `logging.apache.org
>*/log4j/A.x*` will be automatically populated using `./mvnw site
>-Drevision=A.B.C`, where `A.B.C` will be determined at runtime as the
>latest published release of major version `A`
>
> #2, I initially didn't want to. Though had calls with Piotr, Ralph, Gary,
> and Matt yesterday, and decided to keep that. #2 causes the Git repository
> to blow up. Matt had some tips, I will propose a workaround soon.
>
> On Mon, Oct 23, 2023 at 1:38 PM Christian Grobmeier 
> wrote:
>
> > This sounds pretty cool Volkan, if I didn't get anything I pretty much
> > like it.
> > One question - you wrote:
> >
> > "we all will enjoy automatically populated Log4j websites."
> >
> > Does this mean we will see our website is updated automatically by CI so
> > we can see in example /log4j/dev?
> > Or what else is "automatically updated"?
> >
> >
> >
> > On Sun, Oct 22, 2023, at 22:20, Volkan Yazıcı wrote:
> > > Currently, we have the following folder structure in the
> > > `logging-log4j-site` repository for the Log4j project:
> > >
> > >- `log4j-1.2.17` – the website generated by the last Log4j 1
> release,
> > >i.e, `1.2.17`
> > >- `log4j-1.2` – symlinks to `log4j-1.2.17`
> > >- `1.x` – symlinks to `log4j-1.2.17`
> > >- ...
> > >- `log4j-2.19.0` – the website generated by the `2.19.0` release
> > >- `log4j-2.20.0` – the website generated by the `2.20.0` release
> > >- `log4j-2.21.0` – the website generated by the `2.21.0` release
> > >- `2.x` – symlinks to `log4j-2.21.0` (the latest Log4j 2 release)
> > >
> > > I propose keeping existing folders as is (hence, *no changes to the
> > > existing URLs!*) and applying following practices:
> > >
> > >1. *Add a `latest` symlink* pointing to the latest stable version.
> > Today
> > >it will point to `2.x`, sometime in the future it will point to
> `3.x`.
> > >   - This will make following URLs possible:
> > >   https://logging.apache.org/log4j/latest
> > >   - This convention is practiced by several other projects, e.g.,
> > >   Spring Boot: https://docs.spring.io/spring-boot/docs/current
> > >2. *Redirect root to `latest`*, i.e., `logging.apache.org/log4j`
> 
> >  will
> > >redirect to `logging.apache.org/log4j/latest`
> 
> > 
> > >3. *Don't create a new folder for every release, but override the
> > `2.x`
> > >folder.*
> > >   - This is okay, since we keep backward compatibility in
> minor+patch
> > >   releases and explicitly provide version for features that are
> > added later
> > >   on (e.g., "starting from 2.17.0 Log4j provides X...")
> > >   - We can set up CI jobs to periodically populate `1.x`, `2.x`,
> > `3.x`,
> > >   `4.x`, etc. websites and avoid the need to generate the website
> > once and
> > >   for all.
> > >   - We will stop polluting the folder structure.
> > >
> > > As a matter of fact, I already implemented this convention for some
> > > projects. All the following URLs work:
> > >
> > >- `logging-parent`
> > >   - logging.apache.org/logging-parent
> > >   - logging.apache.org/logging-parent/latest
> > >   - logging.apache.org/logging-parent/10.x
> > >- `logging-log4j-kotlin`
> > >   - logging.apache.org/log4j/kotlin
> > >   - logging.apache.org/log4j/kotlin/latest
> > >   - logging.apache.org/log4j/kotlin/1.x
> > >- `logging-log4j-scala`
> > >   - logging.apache.org/log4j/scala
> > >   - logging.apache.org/log4j/scala/latest
> > >   - logging.apache.org/log4j/scala/13.x
> > >- `logging-log4j-tools`
> > >   - logging.apache.org/log4j/tools
> > >   - logging.apache.org/log4j/tools/latest
> > >   - logging.apache.org/log4j/tools/0.x
> > >- `logging-log4j-transform`
> > >   - logging.apache.org/log4j/transform
> > >   - logging.apache.org/log4j/transform/latest
> > >   - logging.apache.org/log4j/transform/0.x
> > >
> > > Unless there are objections, I will update the CI in this direction and
> > we
> > > all will enjoy automatically populated Log4j websites.
> >
>

Re: [log4j] Project URLs per major version

[Volkan Yazıcı]

Let me elaborate on what I want to achieve with CI automation.

*[I will focus on Log4j, but my statements apply to other Maven-based
products as well; Log4j Tools, Log4j Kotlin, etc.]*

   1. When a new Log4j `release/A.B.C` branch is detected, `logging
   *-log4j-A_B_C.staged*.apache.org` will be automatically populated using
   `./mvnw site`
   2. When a new Log4j release of version `A.B.C` is detected, `
   logging.apache.org*/log4j/A.B.C*` will be automatically populated using
   `./mvnw site`
   3. When a change in `A.x` branch is detected, `logging.apache.org
   */log4j/A.x*` will be automatically populated using `./mvnw site
   -Drevision=A.B.C`, where `A.B.C` will be determined at runtime as the
   latest published release of major version `A`

#2, I initially didn't want to. Though had calls with Piotr, Ralph, Gary,
and Matt yesterday, and decided to keep that. #2 causes the Git repository
to blow up. Matt had some tips, I will propose a workaround soon.

On Mon, Oct 23, 2023 at 1:38 PM Christian Grobmeier 
wrote:

> This sounds pretty cool Volkan, if I didn't get anything I pretty much
> like it.
> One question - you wrote:
>
> "we all will enjoy automatically populated Log4j websites."
>
> Does this mean we will see our website is updated automatically by CI so
> we can see in example /log4j/dev?
> Or what else is "automatically updated"?
>
>
>
> On Sun, Oct 22, 2023, at 22:20, Volkan Yazıcı wrote:
> > Currently, we have the following folder structure in the
> > `logging-log4j-site` repository for the Log4j project:
> >
> >- `log4j-1.2.17` – the website generated by the last Log4j 1 release,
> >i.e, `1.2.17`
> >- `log4j-1.2` – symlinks to `log4j-1.2.17`
> >- `1.x` – symlinks to `log4j-1.2.17`
> >- ...
> >- `log4j-2.19.0` – the website generated by the `2.19.0` release
> >- `log4j-2.20.0` – the website generated by the `2.20.0` release
> >- `log4j-2.21.0` – the website generated by the `2.21.0` release
> >- `2.x` – symlinks to `log4j-2.21.0` (the latest Log4j 2 release)
> >
> > I propose keeping existing folders as is (hence, *no changes to the
> > existing URLs!*) and applying following practices:
> >
> >1. *Add a `latest` symlink* pointing to the latest stable version.
> Today
> >it will point to `2.x`, sometime in the future it will point to `3.x`.
> >   - This will make following URLs possible:
> >   https://logging.apache.org/log4j/latest
> >   - This convention is practiced by several other projects, e.g.,
> >   Spring Boot: https://docs.spring.io/spring-boot/docs/current
> >2. *Redirect root to `latest`*, i.e., `logging.apache.org/log4j`
>  will
> >redirect to `logging.apache.org/log4j/latest`
> 
> >3. *Don't create a new folder for every release, but override the
> `2.x`
> >folder.*
> >   - This is okay, since we keep backward compatibility in minor+patch
> >   releases and explicitly provide version for features that are
> added later
> >   on (e.g., "starting from 2.17.0 Log4j provides X...")
> >   - We can set up CI jobs to periodically populate `1.x`, `2.x`,
> `3.x`,
> >   `4.x`, etc. websites and avoid the need to generate the website
> once and
> >   for all.
> >   - We will stop polluting the folder structure.
> >
> > As a matter of fact, I already implemented this convention for some
> > projects. All the following URLs work:
> >
> >- `logging-parent`
> >   - logging.apache.org/logging-parent
> >   - logging.apache.org/logging-parent/latest
> >   - logging.apache.org/logging-parent/10.x
> >- `logging-log4j-kotlin`
> >   - logging.apache.org/log4j/kotlin
> >   - logging.apache.org/log4j/kotlin/latest
> >   - logging.apache.org/log4j/kotlin/1.x
> >- `logging-log4j-scala`
> >   - logging.apache.org/log4j/scala
> >   - logging.apache.org/log4j/scala/latest
> >   - logging.apache.org/log4j/scala/13.x
> >- `logging-log4j-tools`
> >   - logging.apache.org/log4j/tools
> >   - logging.apache.org/log4j/tools/latest
> >   - logging.apache.org/log4j/tools/0.x
> >- `logging-log4j-transform`
> >   - logging.apache.org/log4j/transform
> >   - logging.apache.org/log4j/transform/latest
> >   - logging.apache.org/log4j/transform/0.x
> >
> > Unless there are objections, I will update the CI in this direction and
> we
> > all will enjoy automatically populated Log4j websites.
>

[ANNOUNCE] Apache Log4j 2.21.1 released

[Piotr P. Karwasz]

Apache Log4j team is pleased to announce the 2.21.1
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the project
website[1].

[1] https://logging.apache.org/log4j

== Release Notes

This patch release contains only the fix of a `log4j-jcl` bug that
prevents it from connecting with `commons-logging`.

The Log4j 2.21.1 API, as well as the other artifacts, maintains binary
compatibility with the previous release.

Apache Log4j 2.21.1 requires Java 8 to run.
The build requires JDK 11 and generates reproducible binaries.

For complete information on Apache Log4j 2, including instructions on
how to submit bug reports, patches, get support, or suggestions for
improvement, see the Apache Log4j 2.x website[2].

[2] http://logging.apache.org/log4j/2.x/

=== Fixed

* Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865)

Piotr