Split migration from Log4j 1 to Log4j 2 API and Log4j 2 Core #154
Comments
|
Hi @ppkarwasz ; thanks for the offer to help! Agree that we can split these concerns and make each of those available as a separate recipe, with perhaps a combined yaml recipe that executes both for convenience. Naming each of these without confusing users might be the hardest part to all of this, but I'm sure we can work out something there. We'll want to differentiate between the logging backend and the logging API, and ensure folks get results that match their expectations when running a recipe. |
If the problem is trying to speed up the recipe running, the bottleneck is not in the recipe running but in building LST to process. So it's not going to be faster. We tend to gather all recipes together to migrate you to the latest no matter what your starting point is, but people do create their own custom recipes for just a subset of recipes (to help review the changes in parts primarily or to exclude optional changes that they don't like). |
This PR uses the [Log4j Configuration Converter API](https://logging.staged.apache.org/log4j/transform/log4j-converter-config.html) to add a `Log4j1ConfigurationToLog4jCore2` rule, which converts `log4j.properties` and `log4j.xml` configuration files into the equivalent `log4j2.xml` configuration files. It also refactors the `Log4j1toLog4j2` recipe into three parts: - `Log4j1toLog4jAPI` performs the migration from the "Log4j 1 API" to Log4j API 2, as described in [Log4j 1 API migration](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#api-migration). This recipe performs almost exclusively Java code changes and is usually not required in applications that use JCL or SLF4J as logging interface. - `Log4j1ConfigurationToLog4jCore2` migrates configuration files, as described in the [Log4j 1 Configuration file migration](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#configuration-file-migration) section. - `Log4j1ToLog4jCore2` migrates the runtime dependencies to use Log4j Core 2 instead of Log4j 1, as described in [Log4j 1 Backend migration](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#backend-migration) and also calls the previous recipe. This is probably the most useful recipe for users that no longer user Log4j 1 directly, but use it as logging implementation. Closes openrewrite#154. Related to apache/logging-log4j2#3220
What problem are you trying to solve?
The Migrate Log4j 1.x to Log4j 2.x recipe, provides steps that:
The second set of migration rules could be refactored into a separate (and faster) recipe.
Nowadays most applications don't use Log4j API in their code: since 2002 JCL and SLF4J have replaced the usage of Log4j 1 in code almost entirely.
However there is a niche of users that kept using Log4j 1 (and its clone Reload4J) as logging backend. These users might be interested in a recipe that only reconfigures their runtime classpath and converts their configuration files.
Describe the solution you'd like
I would like to move the rules that change dependencies from the
Log4j1ToLog4j2recipe to a newLog4j1ToLog4j2Corerecipe and use the latter in the former.Are you interested in contributing this feature to OpenRewrite?
I will contribute this feature in late Q3 2023, enhanced with a Log4j 1 to Log4j 2 configuration format converter.
The text was updated successfully, but these errors were encountered: