Re: (logging-log4j2) branch 2.x updated: Backport Lazy util
I split this one up by accident. There was a follow up commit that updated the
places where they were updated in main. I don’t recall any particular issue
being resolved, though I was comparing the 2.x and main branches to look for
differences. Guess I did it in reverse here.
—
Matt Sicker
> On Nov 5, 2023, at 00:08, Ralph Goers wrote:
>
> 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 r
Re: Features for 3.x was: Why is JNDI still necessary?
> On Nov 4, 2023, at 00:08, Christian Grobmeier wrote: > […] > > Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next > year" seems to be quite of a rush. After another beta release, I don’t think that’s a rush. It’s not like the entire ecosystem will upgrade all at once! > As far as I know, we still have changes in 2.x that are not in 3.x. Any missing changes are likely minor and can be included in 3.0.1 or 3.1.0. We can do a diff between branches more easily now that they’ve been somewhat reformatted when combined with `git diff -w` to ignore whitespace changes, and this can reveal relevant changes. I’ve looked at some of that recently, and it looks like there are pom.xml differences, but I wasn’t finding much relevant changes from the bits I sampled. > 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. I was wondering why the 2.x branch builds faster than main, but that’s not a blocker for releases. > 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 Flume doesn’t require a massive rewrite or anything like that. In fact, it could probably use trimming down of some now irrelevant modules. >>> 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. The audit web app thing is a single user application that you can realistically only run locally. It’s all offline software besides the API, and the API depends on Log4j API which can be overridden by the user. >> Others have expressed things they would like to do because it is a >> major release and so some end-user impact is allowable. But most, if >> not all, of the things I have seen proposed could be done post 3.0 GA. >> So no, it is not a requirement that they be addressed. For example, >> Matt did a lot of work on the DI system. It took him forever. None of >> it was required. It was/is very beneficial to do but it wasn’t required. > > Why do you bring up Matts work here? It seems unrelated. The biggest change we wanted for 3.x was related to JPMS support and beginning to break out a large portion of log4j-core into separate modules. That was completed a while back. I did work on a few iterations of the plugin system to transform it into a more generic DI system, but that’s largely an implementation detail that could have been done post-3.0 as it was designed to be backward-compatible (which itself took some finagling to figure out how to unify, but it’s fine now). There have been some things I’ve changed that should be done before 3.0, but those largely involved removal of deprecated code and some small changes to APIs (such as flattening of extension interfaces, removal of Serializable, removal of the generic parameter from Layout). We can do some additional passes for anything else that should be cleaned up before 3.0, but it’s not much. I’ve suggested that we annotate code around API compatibility guarantees, and we are using @InternalApi in main to mark things that shouldn’t be used as stable code (even if it’s unlikely to change over time). — Matt Sicker
Re: Features for 3.x was: Why is JNDI still necessary?
> On Nov 5, 2023, at 2:58 PM, Matt Sicker wrote: > I’ve suggested that we annotate code around API compatibility guarantees, and > we are using @InternalApi in main to mark things that shouldn’t be used as > stable code (even if it’s unlikely to change over time). > Please be careful of your usage of the term “API”. Log4j-API is one thing. Very little in it should be private but there is some stuff. We have done a decent job of adding comments of “consider this priviate” but using annotations and any tooling we can to enforce that would greatly help. As for the other modules, Log4j-Plugins obviously has a publicly exposed API. That was intentional as my hope is that eventually Log4j-Plugins could become a general use framework, not specific to Log4j. Log4j-Core is where the real meat of this is. If we wanted to be really clear we could have split log4j-core into log4j-core-api and log4j-core-impl but using JPMS and annotations should be enough. Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
I added @InternalApi to all the classes that were marked “consider this class private”. As for the plugins, yes, now that we’ve got that stabilized, I think that makes sense to keep stable, too. — Matt Sicker > On Nov 5, 2023, at 16:22, Ralph Goers wrote: > > > >> On Nov 5, 2023, at 2:58 PM, Matt Sicker wrote: > >> I’ve suggested that we annotate code around API compatibility guarantees, >> and we are using @InternalApi in main to mark things that shouldn’t be used >> as stable code (even if it’s unlikely to change over time). >> > > Please be careful of your usage of the term “API”. Log4j-API is one thing. > Very little in it should be private but there is some stuff. We have done a > decent job of adding comments of “consider this priviate” but using > annotations and any tooling we can to enforce that would greatly help. > > As for the other modules, Log4j-Plugins obviously has a publicly exposed API. > That was intentional as my hope is that eventually Log4j-Plugins could become > a general use framework, not specific to Log4j. Log4j-Core is where the real > meat of this is. If we wanted to be really clear we could have split > log4j-core into log4j-core-api and log4j-core-impl but using JPMS and > annotations should be enough. > > Ralph >
