Re: End-of-life date for `log4j-1.2-api`

[Piotr P. Karwasz]

Hi Ralph,

On Mon, 22 Apr 2024 at 03:35, Ralph Goers  wrote:
>
> Did we make a decision on this?

Since apparently there is consensus in the PMC, I opened an issue[1]
and I am going to remove `log4j-1.2-api` from the `main` branch.

Piotr

[1] https://github.com/apache/logging-log4j2/issues/2461

Re: Canonicalization of URLs on our website

[Ralph Goers]

I have always viewed index.html as a special case. When navigating to the root 
of a site - l.a.o/log4j/2.x/ - should be sufficient as it should default to 
index.html. However, the “real” url includes index.html. 

Other pages should always be whatever.html IMO. 

Ralph

> On Apr 20, 2024, at 1:17 PM, Piotr P. Karwasz  wrote:
> 
> Hi,
> 
> I scanned our https://logging.apache.org/ website and found out that
> the internal hyperlinks between our pages are not consistent. For
> example links to:
> 
> https://logging.apache.org/log4j/2.x/
> 
> might appear in hyperlinks with an URI path of:
> 
> * `/log4j/2.x` (which causes a 301 HTTP redirect),
> * `/log4j/2.x/`,
> * `/log4j/2.x/index.html`.
> 
> This lack of uniformity can cause several problems:
> 
> * search engines might treat those 3 links as equivalent, but not necessarily.
> * if an `index.html` file is moved, we need to provide a redirect for
> all 3 alternatives: a recent example is
> `/log4j/2.x/log4j-1.2-api/index.html` that was moved to
> `/log4j2/2.x/log4j-1.2-api.html`.
> * for the rare people that actually look at the URL of a page, it
> doesn't seem coherent.
> 
> So I would propose to adopt only one of the 3 alternatives and stick
> to it as much as possible? Which one should we choose?
> 
> The simplest one (`/log4j/2.x/index.html`) does not require a Web
> server and can be viewed locally and can be viewed using the `file:`
> scheme in a browser. However I find it less elegant than
> `/log4j/2.x/`.
> Antora is probably able to generate both versions through some
> configuration option, so choosing `/log4j/2.x/` does not preclude the
> possibility to generate a different version to check the web site
> locally.
> 
> Another canonicalization we might apply regards trailing `.html`
> extensions in the URL. The current website supports both:
> 
> * `/log4j2/log4j-api`,
> * `/log4j2/log4j-api.html`.
> 
> through `mod_negotiation`. Should we use the version with a trailing
> `.html` or without it? The `https://apache.org/` website hides the
> `.html` extension in most the links.
> 
> Piotr

Re: End-of-life date for `log4j-1.2-api`

[Ralph Goers]

Did we make a decision on this?

Ralph

> On Apr 8, 2024, at 4:02 PM, Ralph Goers  wrote:
> 
> 
> 
>> On Apr 8, 2024, at 2:40 PM, Jochen Wiedmann  
>> wrote:
>> 
>> On Mon, Apr 8, 2024 at 1:11 PM Apache  wrote:
>> 
>>> My opinion is to drop it from 3.0.0. 2.x is going to live a long time 
>>> still. By the time it dies Log4J 1.x will have been dead well over 15 
>>> years, maybe even 20. That would give users plenty of time to be aware that 
>>> they need to plan to upgrade.
>> 
>> How long ago was it, that all these JNDI, and JMS related issues where
>> found? Yes, three years. And I remember very well, how customers
>> basically stormed my employers house, because some ancient code (which
>> should have been updated years ago) is using these "dead" libraries.
>> 
>> And, do you remember also, how long it took at the time, to push out
>> 1.2.18? Wait, that was never published? Instead, we have
>> https://github.com/qos-ch/reload4j.
>> 
>> Please, just because you think, that you can master these things:
>> Don't assume, that others can.
> 
> I think you missed the point. Log4j 3.x will ONLY support Java 17 and above. 
> That would mean that someone would have had to port & verify that code 
> written for pre-Java 6 now runs on Java 17+ in order to use Log4j 3.x to 
> support their Log4j 1.x application.
> 
> As I said, Log4j 2.x isn’t going away any time soon. Even then, I suspect 
> that log4j-1.2-api from Log4j 2.x will probably work with the rest of Log4j 
> 3.x especially now that Log4j API is staying at 2.x (although at some point 
> its minimum JDK will be upgraded). It is possible that we may decide to fork 
> the 1.2 API module into its own repo after the rest of 2.x is retired. Who 
> knows? That will be years from now.  
> 
> All we are deciding here is to NOT include it in 3.x.
> 
> Ralph

Re: Canonicalization of URLs on our website

[Volkan Yazıcı]

I have a couple of questions Piotr:

   1. Could you show us the Antora configuration option you mentioned
   and how we can use it to achieve what you propose?
   2. Are you suggesting that all `foo.html` pages should be converted to
   `foo/`?


On Sat, Apr 20, 2024 at 10:17 PM Piotr P. Karwasz 
wrote:

> Hi,
>
> I scanned our https://logging.apache.org/ website and found out that
> the internal hyperlinks between our pages are not consistent. For
> example links to:
>
> https://logging.apache.org/log4j/2.x/
>
> might appear in hyperlinks with an URI path of:
>
> * `/log4j/2.x` (which causes a 301 HTTP redirect),
> * `/log4j/2.x/`,
> * `/log4j/2.x/index.html`.
>
> This lack of uniformity can cause several problems:
>
> * search engines might treat those 3 links as equivalent, but not
> necessarily.
> * if an `index.html` file is moved, we need to provide a redirect for
> all 3 alternatives: a recent example is
> `/log4j/2.x/log4j-1.2-api/index.html` that was moved to
> `/log4j2/2.x/log4j-1.2-api.html`.
> * for the rare people that actually look at the URL of a page, it
> doesn't seem coherent.
>
> So I would propose to adopt only one of the 3 alternatives and stick
> to it as much as possible? Which one should we choose?
>
> The simplest one (`/log4j/2.x/index.html`) does not require a Web
> server and can be viewed locally and can be viewed using the `file:`
> scheme in a browser. However I find it less elegant than
> `/log4j/2.x/`.
> Antora is probably able to generate both versions through some
> configuration option, so choosing `/log4j/2.x/` does not preclude the
> possibility to generate a different version to check the web site
> locally.
>
> Another canonicalization we might apply regards trailing `.html`
> extensions in the URL. The current website supports both:
>
> * `/log4j2/log4j-api`,
> * `/log4j2/log4j-api.html`.
>
> through `mod_negotiation`. Should we use the version with a trailing
> `.html` or without it? The `https://apache.org/` 
> website hides the
> `.html` extension in most the links.
>
> Piotr
>

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

[Gary Gregory]

And for main: https://github.com/apache/logging-log4j2/pull/2493

Gary

On Thu, Apr 18, 2024 at 10:21 AM Gary D. Gregory  wrote:
>
> TY for your help Piotr.
>
> The PR for the 2.x part is here 
> https://github.com/apache/logging-log4j2/pull/2486
>
> Gary
>
> On 2024/04/18 02:58:39 "Gary D. Gregory" wrote:
> > Hi Piotr,
> >
> > Please see the branch feature/2.x/mongodb-next and its failing tests.
> >
> > TY,
> > Gary
> >
> > On 2024/04/17 21:59:45 "Gary D. Gregory" wrote:
> > > This is the plan that Piotr and I came up with one addition (1c):
> > >
> > > 1. Branch 2.x
> > > 1.a. Drop module log4j-mongodb3
> > > 1.b. Add module log4j-mongodb (no number) that contains one class that 
> > > instantiates the log4j-mongodb4 provider. XML element is MongoDb.
> > > 1.c. Deprecate module log4j-mongodb4 in favor of log4j-mongodb
> > >
> > > 2. Branch main
> > > 2.a. Rename module log4j-mongodb4 to module log4j-mongodb
> > > 2.b. Rename XML element MongoDb4 to MongoDb
> > >
> > > Gary
> > >
> > > On 2024/04/17 19:49:40 "Piotr P. Karwasz" wrote:
> > > > Hi Gary,
> > > >
> > > > On Wed, 17 Apr 2024 at 21:23, Gary Gregory  
> > > > wrote:
> > > > > But then your config has to say  AND depend on the mongodb5
> > > > > module! Still confusing 
> > > >
> > > > There is actually a rarely used feature of our plugin system, where a
> > > > plugin named `Foo` can actually create an object of type `Bar`. See
> > > > for example the `LoggerConfig.Root` plugin that actually creates an
> > > > object of type `LoggerConfig`.
> > > >
> > > > In your config you will use `MongoDb5`, but the provider will be of
> > > > type MongoDb4Provider.
> > > >
> > > > Piotr
> > > >
> > >
> >