Re: [VOTE] Release log4cxx 1.0.0

[Remko Popma]

+1 Remko

On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning 
wrote:

> Guten Tag Robert Middleton,
> am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:
>
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
>
> +1
>
> I've successfully compiled and ran all tests using MS Visual Studio
> 17.4.3 64 Bit under Windows 10 22H2 19045.2364 64 Bit.
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   +49 5151-  9468- 0
> Tel:   +49 5151-  9468-55
> Mobil: +49  178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
> Telefon: +49 5151 9468-55
> Fax:
> E-Mail: tschoen...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen und ist ausschliesslich für den Adressaten bestimmt.
> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten
> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung
> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> Vertrauen auf erlangte Information untersagt.
>
> This e-mail may contain confidential and/or privileged information and is
> intended solely for the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient (or have received this
> e-mail in error) please notify the sender immediately and destroy this
> e-mail. If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it,
> is prohibited and may be unlawful.
>
> Hinweise zum Datenschutz: bitstore.group/datenschutz
>
>
>
>

Re: Log4j Maven plugin

[Volkan Yazıcı]

I disagree with putting these into `logging-log4j-tools` with the current
state of the project: It is intended for *internal* usage. For
`log4j-changelog`, I want to make it explicit that it is not intended for
usage outside Log4j itself. I have two proposals:

   1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`)
   repository and move the `log4j-changelog` module there and put Piotr's
   stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`)
   2. Move everybody to their own repo: `logging-log4j-changelog`,
   `logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This might
   turn out to be a better approach given aforementioned projects will most
   probably have totally different development cycles.

What do you think?

Regarding code rewrites, i.e., `log4j-errorprone`, Spring Boot 3 has
introduced Spring Boot Migrator
,
which uses OpenRewrite  under the hood.
Judging from my personal experience, code rewrite functionality in Error
Prone never got mass adoption and Spring is really influential in the Java
domain. I expect OpenRewrite to get quite some steam in the near future.

On Tue, Jan 3, 2023 at 1:50 AM Ralph Goers 
wrote:

> I think putting it in the tools repo would be fine.
>
> Ralph
>
> > On Jan 2, 2023, at 2:34 PM, Piotr P. Karwasz 
> wrote:
> >
> > Hi,
> >
> >> On Mon, 2 Jan 2023 at 10:08, Volkan Yazıcı  wrote:
> >> Agreed with the separate repository idea. I suggest moving it to the
> >> `logging-log4j-maven-plugins` repository – you need an INFRA ticket to
> >> create the repository.
> >
> > The Maven plugin will not be the only use-case of the code after I
> > finish up the project.
> >
> > Since I am really bad at naming things, so maybe I'll describe the
> > feature-set and someone will come with the ideal name. :-D
> >
> > I imagine one module that will weave bytecode (`log4j-instrument`) to:
> > * convert classical Log4j2 API calls to LogBuilder calls with location,
> > * convert other API calls (Log4j 1.2, JCL, SLF4J and especially
> > `java.util.logging`) to Log4j2 API calls (LogBuilder with location for
> > now),
> > * implement `java.lang.instrument.ClassFileTransformer` so that we
> > can use it to weave at runtime.
> >
> > A second module would be based on a refactoring library (Error Prone?
> > called `log4j-errorprone`?) to:
> > * convert classical Log4j2 API calls to LogBuilder (this simplifies
> > weaving a lot),
> > * convert other API calls to Log4j2 API,
> > * check for common mistakes of new Log4j2 API adopters: e.g. `if
> > (logger.isDebugEnabled() logger.debug(...);` or `logger.debug("Hello
> > name " + name + ".")`.
> >
> > A Maven module would use `log4j-instrument` to:
> > * weave a project's classes,
> > * weave all JAR dependencies (well, with some default exclusion
> > patterns such as `log4j-*.jar` of course),
> > * create a POM that only references Log4j2 API.
> >
> > And of course Maven is not the only build tool on the market.
> > Contributors could submit plugins for other build tools.
> >
> > I think that `logging-log4j-tools` would be a nice name for a
> > repository, but it is taken. :-) Unless `log4j-changelog` is targeted
> > at a larger audience, in which case we can share. :-)
> >
> > Piotr
>
>

Re: Syncing `master`

[Volkan Yazıcı]

That sounds like a great sweet spot to settle on. We can periodically
(hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
commits older than 24 hours have a subject-matching counterpart in `master`
(and vice versa), if not, creates a GitHub Issue assigned to the author of
the commit and referencing to the commit.

Anybody else objecting, except Ralph?

On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı  wrote:
> > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > telling commit X needs to be reflected on branch Y whenever a commit
> lands
> > on branch Z?
> >
> > If you all agree, I volunteer to set this up.
>
> If you can add a time delay, that would be fantastic.
>
> I imagine some logic like: if 24 hours have passed and the commit with
> a subject line "Hello World!" on `release-2.x` does not have a commit
> in `master` with the same subject, create an issue. Commits that need
> a subject change (like "Deprecate for removal" -> "Remove") are rare
> and a committer can always close those issues manually.
>
> Piotr
>

Re: Syncing `master`

[Gary Gregory]

Sounds like it could backfire in some cases creating busy work: What
happens when I commit to 2.x for code that has been deprecated or removed
in 3.x? Certainly we don't want to create tickets for those. Do I have to
remember to put a special comment in the commit message?

Gary

On Tue, Jan 3, 2023, 04:01 Volkan Yazıcı  wrote:

> That sounds like a great sweet spot to settle on. We can periodically
> (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> commits older than 24 hours have a subject-matching counterpart in `master`
> (and vice versa), if not, creates a GitHub Issue assigned to the author of
> the commit and referencing to the commit.
>
> Anybody else objecting, except Ralph?
>
> On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz 
> wrote:
>
> > Hi Volkan,
> >
> > On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı  wrote:
> > > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > > telling commit X needs to be reflected on branch Y whenever a commit
> > lands
> > > on branch Z?
> > >
> > > If you all agree, I volunteer to set this up.
> >
> > If you can add a time delay, that would be fantastic.
> >
> > I imagine some logic like: if 24 hours have passed and the commit with
> > a subject line "Hello World!" on `release-2.x` does not have a commit
> > in `master` with the same subject, create an issue. Commits that need
> > a subject change (like "Deprecate for removal" -> "Remove") are rare
> > and a committer can always close those issues manually.
> >
> > Piotr
> >
>

Re: Syncing `master`

[Volkan Yazıcı]

I assume such cases to be relatively infrequent. If not, we can introduce a
commit message magic word to disarm the mechanism. All in all, is clicking
on the _Close_ button of a ticket really that difficult?

Note that these tickets would also constitute a good historical account for
hinting the divergence between multiple release branches.

On Tue, Jan 3, 2023 at 12:20 PM Gary Gregory  wrote:

> Sounds like it could backfire in some cases creating busy work: What
> happens when I commit to 2.x for code that has been deprecated or removed
> in 3.x? Certainly we don't want to create tickets for those. Do I have to
> remember to put a special comment in the commit message?
>
> Gary
>
> On Tue, Jan 3, 2023, 04:01 Volkan Yazıcı  wrote:
>
> > That sounds like a great sweet spot to settle on. We can periodically
> > (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> > commits older than 24 hours have a subject-matching counterpart in
> `master`
> > (and vice versa), if not, creates a GitHub Issue assigned to the author
> of
> > the commit and referencing to the commit.
> >
> > Anybody else objecting, except Ralph?
> >
> > On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <
> piotr.karw...@gmail.com>
> > wrote:
> >
> > > Hi Volkan,
> > >
> > > On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı  wrote:
> > > > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > > > telling commit X needs to be reflected on branch Y whenever a commit
> > > lands
> > > > on branch Z?
> > > >
> > > > If you all agree, I volunteer to set this up.
> > >
> > > If you can add a time delay, that would be fantastic.
> > >
> > > I imagine some logic like: if 24 hours have passed and the commit with
> > > a subject line "Hello World!" on `release-2.x` does not have a commit
> > > in `master` with the same subject, create an issue. Commits that need
> > > a subject change (like "Deprecate for removal" -> "Remove") are rare
> > > and a committer can always close those issues manually.
> > >
> > > Piotr
> > >
> >
>

Re: Syncing `master`

[Ralph Goers]

I don’t necessarily object to this version of the proposal. While not perfect 
it should eliminate most of the noise.

Ralph

> On Jan 3, 2023, at 2:01 AM, Volkan Yazıcı  wrote:
> 
> That sounds like a great sweet spot to settle on. We can periodically
> (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> commits older than 24 hours have a subject-matching counterpart in `master`
> (and vice versa), if not, creates a GitHub Issue assigned to the author of
> the commit and referencing to the commit.
> 
> Anybody else objecting, except Ralph?
> 
> On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı  wrote:
>>> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
>>> telling commit X needs to be reflected on branch Y whenever a commit
>> lands
>>> on branch Z?
>>> 
>>> If you all agree, I volunteer to set this up.
>> 
>> If you can add a time delay, that would be fantastic.
>> 
>> I imagine some logic like: if 24 hours have passed and the commit with
>> a subject line "Hello World!" on `release-2.x` does not have a commit
>> in `master` with the same subject, create an issue. Commits that need
>> a subject change (like "Deprecate for removal" -> "Remove") are rare
>> and a committer can always close those issues manually.
>> 
>> Piotr
>> 

Re: Log4j Maven plugin

[Piotr P. Karwasz]

Hi Volkan,

On Tue, 3 Jan 2023 at 09:45, Volkan Yazıcı  wrote:
>1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`)
>repository and move the `log4j-changelog` module there and put Piotr's
>stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`)
>2. Move everybody to their own repo: `logging-log4j-changelog`,
>`logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This might
>turn out to be a better approach given aforementioned projects will most
>probably have totally different development cycles.

What about `logging-log4j-transform`? The Maven plugin could be called
`log4j-transform-maven-plugin` in case we publish other plugins.

For the groupId I think `org.apache.logging.log4j` that Ralph proposes
will be fine.

Piotr

[GitHub] [logging-log4j1] ppkarwasz opened a new pull request, #23: Helps automatic detection of security policy

[GitBox]

ppkarwasz opened a new pull request, #23:
URL: https://github.com/apache/logging-log4j1/pull/23

   Helps automatic detecting the security policy that applies to Log4j 1.2 
(i.e. end-of-life), but using an established file name.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Log4j Maven plugin

[Volkan Yazıcı]

`logging-log4j-transform` and `org.apache.logging.log4j` are fine by me.

On Tue, Jan 3, 2023 at 6:43 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Tue, 3 Jan 2023 at 09:45, Volkan Yazıcı  wrote:
> >1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`)
> >repository and move the `log4j-changelog` module there and put Piotr's
> >stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`)
> >2. Move everybody to their own repo: `logging-log4j-changelog`,
> >`logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This
> might
> >turn out to be a better approach given aforementioned projects will
> most
> >probably have totally different development cycles.
>
> What about `logging-log4j-transform`? The Maven plugin could be called
> `log4j-transform-maven-plugin` in case we publish other plugins.
>
> For the groupId I think `org.apache.logging.log4j` that Ralph proposes
> will be fine.
>
> Piotr
>

Re: [VOTE] Release log4cxx 1.0.0

[Stephen Webb]

+1

I have built and tested the .zip archive using Visual Studio 2019.

I tested the .taz.gz archive with gcc 9.4 on Ubuntu

On Tue, Jan 3, 2023 at 7:37 PM Remko Popma  wrote:

> +1 Remko
>
> On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning 
> wrote:
>
> > Guten Tag Robert Middleton,
> > am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:
> >
> > > Please download, test, and cast your votes on the log4j developers
> list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> >
> > +1
> >
> > I've successfully compiled and ran all tests using MS Visual Studio
> > 17.4.3 64 Bit under Windows 10 22H2 19045.2364 64 Bit.
> >
> > Mit freundlichen Grüßen
> >
> > Thorsten Schöning
> >
> > --
> > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und
> TK
> >
> > E-Mail: thorsten.schoen...@am-soft.de
> > Web:http://www.AM-SoFT.de/
> >
> > Tel:   +49 5151-  9468- 0
> > Tel:   +49 5151-  9468-55
> > Mobil: +49  178-8 9468-04
> >
> > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> > Hameln
> > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> >
> >
> > Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> >
> > Telefon: +49 5151 9468-55
> > Fax:
> > E-Mail: tschoen...@am-soft.de
> >
> > AM-Soft IT-Service - Bitstore Hameln GmbH
> > Brandenburger Straße 7c
> > 31789 Hameln
> >
> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> > Informationen und ist ausschliesslich für den Adressaten bestimmt.
> > Jeglicher Zugriff auf diese E-Mail durch andere Personen als den
> Adressaten
> > ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail
> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> > vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> > bestimmte Adressat sein, ist Ihnen jede Veröffentlichung,
> Vervielfältigung
> > oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> > Vertrauen auf erlangte Information untersagt.
> >
> > This e-mail may contain confidential and/or privileged information and is
> > intended solely for the addressee. Access to this email by anyone else is
> > unauthorized. If you are not the intended recipient (or have received
> this
> > e-mail in error) please notify the sender immediately and destroy this
> > e-mail. If you are not the intended recipient, any disclosure, copying,
> > distribution or any action taken or omitted to be taken in reliance on
> it,
> > is prohibited and may be unlawful.
> >
> > Hinweise zum Datenschutz: bitstore.group/datenschutz
> >
> >
> >
> >
>

Re: Log4j Maven plugin

[Ralph Goers]

I do like this as a separate repo. If I understand what you are intending I 
expect that releasing this tool will be big news:
1. It automatically converts calls to SLF4J to Log4j, eliminating the need to 
include the SLF4J and log4j-slf4j-impl jars at runtime.
2. It adds location information for free for both SLF4J and Log4j API calls, 
which should be a significant performance improvement.

One gotcha we will need to make sure is accounted for is the use of Lombok. 
Will the tool be able to find the Logger created by Lombok?

Ralph

> On Jan 3, 2023, at 12:35 PM, Volkan Yazıcı  wrote:
> 
> `logging-log4j-transform` and `org.apache.logging.log4j` are fine by me.
> 
> On Tue, Jan 3, 2023 at 6:43 PM Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Tue, 3 Jan 2023 at 09:45, Volkan Yazıcı  wrote:
>>>   1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`)
>>>   repository and move the `log4j-changelog` module there and put Piotr's
>>>   stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`)
>>>   2. Move everybody to their own repo: `logging-log4j-changelog`,
>>>   `logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This
>> might
>>>   turn out to be a better approach given aforementioned projects will
>> most
>>>   probably have totally different development cycles.
>> 
>> What about `logging-log4j-transform`? The Maven plugin could be called
>> `log4j-transform-maven-plugin` in case we publish other plugins.
>> 
>> For the groupId I think `org.apache.logging.log4j` that Ralph proposes
>> will be fine.
>> 
>> Piotr
>>