Re: Features for 3.x was: Why is JNDI still necessary?

[Ralph Goers]

> On Nov 3, 2023, at 10:08 PM, Christian Grobmeier  wrote:
> 
> 
>> However, like myself, organizations are not going to delay upgrading 
>> too long. Having Log4j 3.x be available before the majority of orgs 
>> switch to Spring 3 will greatly improve its adoption.
> 
> Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next 
> year" seems to be quite of a rush. 

“Quite of a rush”? Really? 

The first code commit of Log4j 2.x was performed by me in May 2010. The first 
alpha release was in July 2012. 2.0 GA was in July 2014. That is approximately 
4 years from first commit to GA with one more alpha, 9 betas, and 2 release 
candidates in between.
In contrast, the release-2.x branch was created in Jan 2018 which left master 
for work on 3.x to begin. The first, and only so far, release was in June of 
this year. That is over 5 years from the initial branch to first release. 

To make matters worse, Log4j 2.x was brand new code. I borrowed from Log4j 
extras for some of the rolling file appender stuff but everything else was 
written from scratch. In contrast, 3.x started from 2.x and has largely been 
refactoring work. So the risks involved with 3.x are much, much lower than what 
we faced with 2.x.

So I have no idea how you can use the word “rushed” to describe the abysmal 
pace 3.x has been proceeding. 


> 
> As far as I know, we still have changes in 2.x that are not in 3.x.
> I heard we lack integration tests and parallel testing in 3.x is disabled. 
> This does not make me feel like a GA, but starting a longer beta phase.

If we have changes in 2.x that are not in 3.x they aren’t many and we will 
never find that out without releasing. In general users don’t want to use 
alphas or betas. The alphas and betas are there so we can get feedback on 
issues such as these but the majority of them won’t appear until a GA release. 
To be clear, we MUST have one or two betas before a GA release precisely 
because we WILL have issues to deal with. This is completely normal and 
expected.
Lack integration tests? Yes 2.x lacks integration tests and always has. Why 
would we delay 3.x for something 2.x doesn’t have. All the integration tests 
will prove is that various log4j modules can coexist together because some of 
them use different dependencies. The unit tests are what matter and they by and 
large pass. That said, I did make the request to create integration tests 
because Gary has always been afraid of breaking Log4j into multiple repos 
because he believes having everything compile and build together provides 
assurance that everything will work together. If everything was using managed 
depdendencies that would be true. But they don’t so it isn’t.
As far as parallel testing goes, so what? That didn’t exist in 2.x until a 
couple of months ago. Again, why do we need to wait. Users don’t care. The only 
real consequence is that the build is slower. I put up with that for years as 
release manager and, to be honest, with the newer hardware that is available 
this problem to a large degree has solved itself. Not that I don’t appreciate 
the builds completeing faster but that should NEVER be a requirement to delay a 
release. If it had we would be one Logj4 2.4 about now.

> 
> With flume, audit and the other stuff eating time, it will be hard to get 
> this done.
 
 Get what done? As far as I am concerned Log4j 3.x can go to beta now 
 and GA the first of the year. There are no required features left, just 
 stuff that would be nice to get done but can be done after the initial 
 GA release.
>>> 
>>> I'm talking about adding Flume to our project, adding the community, and 
>>> maintaining the new component. 
>> 
>> Up til now that is all pretty much me. I expect it will stay that way 
>> for a time, although Matt has indicated an interest in contributing.
> 
> Yes, that time you don't have for 3.x

Huh? As far as I know everything I had to work on for 3.x was done prior to 
alpha1. What are you talking about?

> 
>>> We have open security issues with log4j-audit, and log4j-server still needs 
>>> to be cleaned up. 
>> 
>> Log4j-Audit has no open security issues. It simply needs dependency 
>> updates. Please don’t conflate one with the other. 
> 
> Ok, great, yes, it is using dependencies with major security holes and does 
> not look maintained, yet it is promoted as a main product on our website. Did 
> we check if it is OK to deliver those dependencies? Upgrading does not seem 
> trivial, we haven't also even started.

WTF does this even have to do with 3.x?

> 
>> Log4j-Server is a 
>> sample. We don’t even release it, so I am not sure why you mention it.
> 
> Because we discussed it, there was no movement because nobody seemed to have 
> the time (or interest).

Discussed what? Releasing Log4j server? I recall no such discussion and would 
have voted -1. That is a security nightmare I have no desire to entertain.

> 
>> 
>>> I am still determining how m

Re: (logging-log4j2) branch 2.x updated: Backport Lazy util

[Ralph Goers]

Matt,

I received 3 emails regarding this lazy stuff being back ported. Is there a 
related issue for this? With the volume of emails I am getting I may have 
missed it but I would like to understand, Furthermore, in none of these commit 
emails did I see a changes file listed? How can I know why you did this without 
that and user’s won’t either since it won’t appear in the release notes.

Note that while I would like to avoid back porting from 3.x if it is being done 
to resolve a bug then I am fine with that. But if this is just a random 
“improvement” please don’t.

Ralph

> On Nov 3, 2023, at 4:22 PM, mattsic...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> mattsicker pushed a commit to branch 2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> 
> 
> The following commit(s) were added to refs/heads/2.x by this push:
> new 4243f7cfce Backport Lazy util
> 4243f7cfce is described below
> 
> commit 4243f7cfceae535c898b863ada75417c0e4217fc
> Author: Matt Sicker 
> AuthorDate: Fri Nov 3 18:18:10 2023 -0500
> 
>Backport Lazy util
> ---
> .../java/org/apache/logging/log4j/util/Lazy.java   |  93 +++
> .../org/apache/logging/log4j/util/LazyBoolean.java |  66 
> .../org/apache/logging/log4j/util/LazyUtil.java| 171 +
> 3 files changed, 330 insertions(+)
> 
> diff --git a/log4j-api/src/main/java/org/apache/logging/log4j/util/Lazy.java 
> b/log4j-api/src/main/java/org/apache/logging/log4j/util/Lazy.java
> new file mode 100644
> index 00..2e0d84b3ce
> --- /dev/null
> +++ b/log4j-api/src/main/java/org/apache/logging/log4j/util/Lazy.java
> @@ -0,0 +1,93 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to you under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.logging.log4j.util;
> +
> +import java.util.Objects;
> +import java.util.function.Function;
> +import java.util.function.Supplier;
> +
> +/**
> + * Provides a lazily-initialized value from a {@code Supplier}.
> + *
> + * @param  type of value
> + */
> +public interface Lazy extends Supplier {
> +/**
> + * Returns the value held by this lazy. This may cause the value to 
> initialize if it hasn't been already.
> + */
> +T value();
> +
> +/**
> + * Returns the value held by this lazy. This may cause the value to 
> initialize if it hasn't been already.
> + */
> +@Override
> +default T get() {
> +return value();
> +}
> +
> +/**
> + * Creates a new lazy value derived from this lazy value using the 
> provided value mapping function.
> + */
> +default  Lazy map(final Function function) 
> {
> +return lazy(() -> function.apply(value()));
> +}
> +
> +/**
> + * Indicates whether this lazy value has been initialized.
> + */
> +boolean isInitialized();
> +
> +/**
> + * Sets this lazy value to the provided value.
> + *
> + * @throws UnsupportedOperationException if this type of lazy value 
> cannot be updated
> + */
> +void set(final T newValue);
> +
> +/**
> + * Creates a strict lazy value using the provided Supplier. The supplier 
> is guaranteed to only be invoked by at
> + * most one thread, and all threads will see the same published value 
> when this returns.
> + */
> +static  Lazy lazy(final Supplier supplier) {
> +Objects.requireNonNull(supplier);
> +return new LazyUtil.SafeLazy<>(supplier);
> +}
> +
> +/**
> + * Creates a lazy value using the provided constant value.
> + */
> +static  Lazy value(final T value) {
> +return new LazyUtil.Constant<>(value);
> +}
> +
> +/**
> + * Creates a lazy value using a weak reference to the provided value.
> + */
> +static  Lazy weak(final T value) {
> +return new LazyUtil.WeakConstant<>(value);
> +}
> +
> +/**
> + * Creates a pure lazy value using the provided Supplier to initialize 
> the value. The supplier may be invoked more
> + * than once, and the return value should be a purely computed value as 
> the result may be a different instance
> + * each time. This is useful for building cache tables and other pure 
> compu