Split off XML configuration into its own module or internal package

[ppkarwasz]

Since java.xml is an optional module in Log4j Core 3.x, we need to protect the users from linkage errors like the one reported in LOG4J2-3681.

I see two way to do it:

• creating a log4j-config-xml module like we did with YAML in Split off YAML configuration into its own module #2142,
• moving the implementation details into their own class/package.

The first solution seems a little bit drastic to me: most users will have java.xml or they will not care about JPMS at all.

Regarding the second one, as far as I know the only way to access optional dependencies that is compatible with all JVMs is to access the implementation via reflection. We might as well move the configuration factory to an internal package and leave only a public facade.

[vy]

I would be in favor of creating a new log4j-config-xml module. A very big part of our users use log4j2.yaml and log4j2.properties. When they migrate to Log4j 3, they will discover log4j-config-* anyway. It is not an embarrassing design detail, but a conscious decision. Let's rejoice at it. 😻