Properties configuration factory
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
Re: Properties configuration factory
+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 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 >
Spring 3 and Log4j 3
FYI - in https://github.com/spring-projects/spring-boot/issues/33450#issuecomment-1883014368 has confirmed that Log4j 3.0.0-beta1 now works correctly with Spring 3.x. Ralph
Re: Spring 3 and Log4j 3
Nice! 😀 On Tue, Jan 9, 2024, 4:45 PM Ralph Goers wrote: > FYI - in > https://github.com/spring-projects/spring-boot/issues/33450#issuecomment-1883014368 > has confirmed that Log4j 3.0.0-beta1 now works correctly with Spring 3.x. > > Ralph
