Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

[Matt Sicker]

Agreed that we can add things back later if needed. +1

> On Jan 15, 2024, at 3:02 PM, Volkan Yazıcı  wrote:
> 
> +1
> 
> Allow me to remind everyone that anything that is removed from `3.0.0` can
> be added again in a follow up minor release, if need arises. Hence, no need
> to be overcautious.
> 
> On Mon, Jan 15, 2024 at 9:50 PM Piotr P. Karwasz 
> wrote:
> 
>> Hi all,
>> 
>> While 3.x is approaching its first stable release as a meteor burning
>> through the sky, its core is getting smaller as it approaches earth.
>> 
>> That is why I would propose to remove two further modules from 3.x:
>> 
>> * The functionality of `log4j-jcl` is included in `commons-logging`
>> version 1.3.0 (and previously it was also provided by `spring-jcl`). I
>> assume that users migrating to Log4j 3.x can also migrate to
>> `commons-logging` 1.3.0.
>> 
>> * The Jetty 9.x logger, which is half of the functionality of
>> `log4j-appserver`, can be replaced by `log4j-slf4j-impl` if the users
>> are willing to migrate to Jetty 10.x. Since community support for
>> Jetty 9.x ended two years ago, I guess user will migrate to a
>> supported Jetty version first and only then think about Log4j 3.x.
>> 
>> * The Tomcat logger (the other half of `log4j-appserver`) is only
>> part of the puzzle of artifacts required to have a fully functional
>> logging system in Tomcat. I usually also needed my own artifacts from
>> copernik-eu/log4j-plugins[1] to have something comparable (but still
>> worse) than what WildFly has. I can adopt this part of
>> `log4j-appserver` into copernik-eu/log4j-plugins and make a release
>> before Log4j 3.0.0 is out. If there is any user interest in it, I can
>> "contribute back" the Tomcat logger and other components in a future
>> release.
>> 
>> What do you think?
>> 
>> [1] https://github.com/copernik-eu/log4j-plugins
>> 

Re: Website repos/branches (again)

[Matt Sicker]

I love this idea, Volkan!

> On Jan 15, 2024, at 3:40 AM, Volkan Yazıcı  wrote:
> 
> -1 on merging multiple websites to a single repository.
> 
> I think documentation should reside in the same repository where sources
> are. I already implemented this for *almost* every repository:
> 
> logging-parent
> logging-log4j-tools
> logging-log4j-transform
> logging-log4j-kotlin
> logging-log4j-scala
> logging-log4j-jakarta
> 
> There is only one left to migrate to this scheme: `logging-log4j2`, which I
> intend to do on February 9 during STF MS12. `logging-site`, `cyclonedx`,
> `activity-monitor` are exceptions, since they are only websites, not source
> code repositories. Hence, your statement of *"the way our website is
> created from multiple repos and branches is somehow incoherent"* is untrue.
> 
> Using *"site next to sources"* scheme, when one checks out a repository, it
> is crystal clear what goes where:
> 
> - the `asf-site` branch for `logging.apache.org`
> - the `asf-staging` branch for `logging.staged.apache.org`
> - the rest of the branches for the source code
> 
> This scheme would enable many benefits:
> 
>   1. Contributors, maintainers, users, etc. can easily locate the site and
>   submit changes with zero a priori knowledge. Cloned the sources? Ready to
>   go.
>   2. Since all Maven-based projects would be sharing the same site scheme,
>   we can automate the website publication in the CI-based release process.
> 
> Those who are concerned about folder structure deviation between
> `afs-{site,staging}` branches and the rest, all you need is a Git worktree:
> 
> $ git clone g...@github.com:
> apache/logging-log4j-tools.git logging-log4j-tools~main
> $ cd logging-log4j-tools~main
> $ git checkout -B asf-site origin/asf-site
> $ git checkout -B asf-staging origin/asf-staging
> $ git worktree add ../logging-log4j-tools~site asf-site
> 
> On Mon, Jan 15, 2024 at 9:34 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi,
>> 
>> As we discussed yesterday the way our website is created from multiple
>> repos and branches is somehow incoherent: some parts of the website
>> have separate repos, other parts have a branch in a code repo, other
>> parts have a branch in a website repo.
>> 
>> For example:
>> 
>> * the `/log4j/jakarta` directory is published from the `asf-site`
>> branch of the `logging-log4j-jakarta` repo (which also contains the
>> code of Log4j Jakarta),
>> * the `/cyclonedx` directory is published from the `cyclonedx` branch
>> of the `logging-site` repo,
>> * the `/log4j` directory is published from the `asf-site` branch of
>> the `logging-log4j-site` repo (dedicated site repo).
>> 
>> This is getting confusing and we need some kind of list to find the
>> repo/branch combination responsible for each part of the site.
>> 
>> I think we should bring some order to it. Since not all the parts of
>> the website are connected to a code repo, my personal preference would
>> be to have everything in `logging-site`, with branches named like:
>> 
>> asf-site
>> cyclonedx/asf-site
>> log4j/asf-site
>> log4j/2.x/asf-site
>> log4j/jakarta/asf-site
>> 
>> Putting an `asf-site` (or another suffix) is a Git requirement since
>> Git does not allow us to have both `asf-site` and `asf-site/log4j`
>> branches.
>> 
>> Anyway, any other convention is good for me, as long as the rules to
>> find the correct branch are not too convoluted.
>> 
>> Piotr
>> 

Re: [log4j] `.asf.yaml` between branches

[Ralph Goers]

> On Jan 16, 2024, at 9:15 AM, Ralph Goers  wrote:
> 
> 
> 
>> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz  
>> wrote:
>> 
>> Hi Ralph,
>> 
>> On Tue, 16 Jan 2024 at 01:56, Ralph Goers  wrote:
>>> 
>>> I don’t understand what it means to keep both staging and publish in 
>>> “asf-site”. By definition, the asf-site branch is the live web-site and 
>>> asf-staging is the staging web site.  Are you talking about the build 
>>> scripts or something?
>> 
>> We are talking about this `.asf.yaml` content:
>> 
>> publish:
>> profile: ~
>> whoami: asf-site
>> subdir: content/logging-parent
>> 
>> staging:
>> profile: ~
>> whoami: asf-staging
>> subdir: content/logging-parent
>> 
>> Due to the `whoami` attribute, the `.asf.yaml` file on both the
>> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
>> the `staging` instruction on `asf-site` and the `publish` instruction
>> on `asf-staging`.
> 
> Thanks. That makes sense then.

Actually, it almost HAS to be that way if you are going to be able to simply do 
a merge from staging to the publish branch to go live.

Ralph

Re: [log4j] `.asf.yaml` between branches

[Ralph Goers]

> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz  
> wrote:
> 
> Hi Ralph,
> 
> On Tue, 16 Jan 2024 at 01:56, Ralph Goers  wrote:
>> 
>> I don’t understand what it means to keep both staging and publish in 
>> “asf-site”. By definition, the asf-site branch is the live web-site and 
>> asf-staging is the staging web site.  Are you talking about the build 
>> scripts or something?
> 
> We are talking about this `.asf.yaml` content:
> 
> publish:
>  profile: ~
>  whoami: asf-site
>  subdir: content/logging-parent
> 
> staging:
>  profile: ~
>  whoami: asf-staging
>  subdir: content/logging-parent
> 
> Due to the `whoami` attribute, the `.asf.yaml` file on both the
> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
> the `staging` instruction on `asf-site` and the `publish` instruction
> on `asf-staging`.

Thanks. That makes sense then.

Ralph

Re: [log4j] Performance figures

[Gary Gregory]

Hi Remko! Just saying "Hi".

Gary

On Tue, Jan 16, 2024, 1:40 AM Remko Popma  wrote:

> I’m open to improvements in this area.
>
> Before going into details or specifics though, I’m curious:
>
> What do we (users, developers and PMC members) consider to be the “value
> proposition” of Log4j? Why should people choose Log4j over the
> alternatives?
>
> This is a positioning question; what are the strengths and weaknesses of
> Log4j and how should Log4j position itself in the market of logging
> solutions?
>
> Remko
>
>
> > On Jan 15, 2024, at 22:05, Gary Gregory  wrote:
> >
> > We should IMO keep this information available _somewhere_, maybe in a
> new
> > stable historical-archival section of the site. I'm not a fan of using
> the
> > wiki because that's yet another place to look for information and it
> feels
> > transitory, unstable (as far as information permanance), and more like
> > something we should use (if at all) as a scratch pad.
> >
> > Gary
> >
> >> On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:
> >>
> >> *TLDR:* I want to remove performance figures from the Log4j website,
> >> because they don't serve any practical value anymore.
> >>
> >> Log4j website shares performance figures in several pages; Performance
> >> ,
> >> Asynchronous
> >> Logging
> >> <
> >>
> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
> >>> ,
> >> Garbage-free Logging
> >>  are
> among
> >> the well-known ones. I want to remove all performance figures and only
> keep
> >> pragmatic recommendations due to following reasons:
> >>
> >>   - *Insufficient relevancy* – Shared figures were mostly produced using
> >>   Log4j version `2.5` and `2.6`. These releases date back from late 2016
> >> and
> >>   *a lot* has changed since then.
> >>   - *Insufficient reliability* – There were many occasions PMC members
> >>   stated they weren't able to reproduce these figures.
> >>   - *Error prone* – As tipped in the website, measuring performance
> >>   correctly is very difficult
> >>   .
> >>   - *Context dependent* – Performance is an extremely subjective term.
> It
> >>   requires context. What kind of an application? What is the application
> >>   load? What is the logging load? What is the logging setup? etc.
> Sharing
> >> a
> >>   meaningful figure here that users can benefit in any way is, IMHO,
> >>   impossible.
> >>   - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt
> if
> >>   any of the existing performance figures (produced using ~8 year old
> >> Log4j)
> >>   are applicable to Log4j 3.
> >>
> >> Will we have no performance figures at all? AFAIC, we need to have a
> >> continuous performance testbed that would not only give users an
> indication
> >> about performance of Log4j over time (in a reproducible way!), but also,
> >> maybe more importantly, guide maintainers on making changes affecting
> >> performance. Some of you might recall: I already had implemented some
> stuff
> >> on this subject and had a "a continuous performance testbed"  project
> in my
> >> first STF projects draft. But we needed to drop it due to other pressing
> >> issues and insufficient budget. We can bring it up again if need (and
> >> budget?) arises. Let me know if you and/or your employer would be
> >> interested in funding such an effort.
> >>
>

Re: [log4j] `.asf.yaml` between branches

[Gary Gregory]

Should these files contain comments to this effect?

Gary

On Tue, Jan 16, 2024, 1:18 AM Piotr P. Karwasz 
wrote:

> Hi Ralph,
>
> On Tue, 16 Jan 2024 at 01:56, Ralph Goers 
> wrote:
> >
> > I don’t understand what it means to keep both staging and publish in
> “asf-site”. By definition, the asf-site branch is the live web-site and
> asf-staging is the staging web site.  Are you talking about the build
> scripts or something?
>
> We are talking about this `.asf.yaml` content:
>
> publish:
>   profile: ~
>   whoami: asf-site
>   subdir: content/logging-parent
>
> staging:
>   profile: ~
>   whoami: asf-staging
>   subdir: content/logging-parent
>
> Due to the `whoami` attribute, the `.asf.yaml` file on both the
> `asf-site` and `asf-staging` branch can be the same. INFRA will ignore
> the `staging` instruction on `asf-site` and the `publish` instruction
> on `asf-staging`.
>
> Piotr
>