On 2023/06/23 06:47:35 Volkan Yazıcı wrote:
> Piotr and I have been contemplating moving Log4j BOM to its separate
> repository with its own release cycle. This need will become even more
> pressing as we start breaking down the Log4j modules to their own
> repository.
>
> Ralph and Piotr alrea
I kind of like the release train idea (quarterly or some regular cadence);
that’s how some of the Spring projects have structured their own releases that
combine several unrelated modules. I would be interested in details on what
kind of release cadence we’d adopt.
> On Jul 7, 2023, at 12:00 PM
Now that we have Log4j 3’s first alpha release out along with some nifty
release tooling, I’d like to discuss the near future of the project. I’ll have
time to work on some of this at my day job, but that requires some future
planning first. Besides the DI system changes that I’m still working o
Hi Ralph,
On Fri, 7 Jul 2023 at 19:00, Ralph Goers wrote:
> ... But maybe I am worrying about nothing and most of the components won’t
> ever be touched.
That is what I think will happen. Even now most of the components
haven't been touched in years.
> This brings up another question. The BOM
Spring HAS to use a release train. There are simply too many artifacts. In
addition, Spring users would get annoyed at having new Spring releases at
random intervals and multiple times per month. This last part is the part I
worry about Log4j, although perhaps our ecosystem isn’t large enough (y
Hi Remko,
On Thu, 29 Jun 2023 at 14:04, Remko Popma wrote:
>
> > 1. Configuration has properties related to async logging:
> `asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These
> should be removed before the split, but I don't know what would be the
> right way to do it.
>
> How wou
> On Jul 7, 2023, at 12:07 PM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Fri, 7 Jul 2023 at 19:00, Ralph Goers wrote:
>> ... But maybe I am worrying about nothing and most of the components won’t
>> ever be touched.
>
> That is what I think will happen. Even now most of the components
>
I think doing some inversion of control is likely sufficient here. That would
entail some sort of interfaces in Core which are implemented by the Async code.
What that looks like, I’m not sure, but it’s a common problem to solve.
> On Jul 7, 2023, at 2:44 PM, Piotr P. Karwasz wrote:
>
> Hi Rem
Funny you should ask.
At the moment I am working on a more generalized version of
MutableThreadContextMapFilter. I envision a Filter that will be able to
reconfigure itself dynamically by querying a service. We have implemented such
as service at my employer but I would like to include it with
