+1 – I liked the idea and the fact that we replaced our custom logic with a well-established library.
Just to make it clear, I am against hosting both the old (`log4j-config-properties-legacy`) and the new (`log4j-config-properties`) modules. On Tue, Jan 9, 2024 at 9:31 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi all, > > As an experiment, I added an alternative implementation of a > properties configuration factory yesterday[1]. > > It is Jackson-based and uses whatever mapping is provided by > `jackson-dataformat-text`. As a result the resulting configuration > file seems much more coherent to me (cf. [3]). If a user asks how to > convert an XML configuration into a properties config, we can forward > him to Jackson's documentation. The new format is slightly different > from the old properties factory, but it is not difficult to convert > one format into the other. > > Since having two configuration factories for the same format doesn't > make sense and the old properties configuration has a lot of quirks > and exceptions to the mapping rules, I would propose to drop it (cf. > PR#2174[4]). > > We can release a `beta2` shortly after and see what users think about it. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/2170 > [2] > https://github.com/FasterXML/jackson-dataformats-text/tree/2.17/properties > [3] > https://github.com/apache/logging-log4j2/blob/main/log4j-config-properties/src/test/resources/JavaPropsConfigurationFactoryTest.properties > [4] https://github.com/apache/logging-log4j2/pull/2174 >
