Add Log4j 1 to Log4j 2 configuration file conversion

[ppkarwasz]

• Closes Split migration from Log4j 1 to Log4j 2 API and Log4j 2 Core #154.
• Related to [MS29] Automatic migration tools #2 apache/logging-log4j2#3220

What's changed?

This PR uses the Log4j Configuration Converter API 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. 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 section.
• Log4j1ToLog4jCore2 migrates the runtime dependencies to use Log4j Core 2 instead of Log4j 1, as described in Log4j 1 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.

What's your motivation?

This PR includes the last missing ingredient for a complete Log4j 1 to Log4j API/Core 2 migration: the conversion of configuration files.

Anything in particular you'd like reviewers to focus on?

This PR is a draft, since the "Log4j Configuration Converter API" it uses hasn't been published yet. We will publish log4j-converter-config as soon as we are reasonably sure that it can be used in OpenRewrite without modifications.

The configuration converter recipe is special, since not only it rewrites the content of a file, but it also can change its type (e.g. from Properties.File to XML.Document). Currently the recipe:

• parses the bytes returned by the "Log4j Configuration Converter API" as UTF-8,
• it writes them as SourceFile of type PlainText regardless of the actual type of the converted file and encodes the file using UTF-8.

Is there a way to skip the decoding/encoding of the converted configuration file? I tried Binary, but in that case printAllAsBytes() fails.

Anyone you would like to review specifically?

@timtebeek

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Thanks @ppkarwasz ! The bot suggestions can be a little confusing at times; it wants you to place the static imports last if that was unclear before. I'll try to review in the coming days! Right now caught up midway through a release and some meetings.

[ppkarwasz]

@timtebeek,

The bot suggestions can be a little confusing at times; it wants you to place the static imports last if that was unclear before.

They are indeed confusing, thanks for the explanation.

I'll try to review in the coming days! Right now caught up midway through a release and some meetings.

I am also working on the 0.3.0 release of Log4j Transform. Unless there are radical changes we need to do in Log4j Transform, this PR can wait until 0.3.0 is released.