[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198790#comment-16198790
]
Stephen Colebourne commented on LOG4J2-2056:
--------------------------------------------
I've written up a wiki page with both SLF4J and Log4J on it to try and work out
what is best. There should be a common strategy between the two projects on
module names. https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs
The module names of the API and "replacer" projects are easy to select.
"Bridge" projects are a pain, but again really have no choice (ironically, the
way SLF4J replaces commons-logging is better than the way Log4J works with it,
when considering JPMS modules).
The key choice however is with the implementation projects which are strange
because only one is allowed.
For Log4J, this is log4j-core and log4j-to-slf4j. Either they both have the
same module name, or they have different module names. The argument for the
same module name is that only one can be active at any one time. By using the
same module name, it allows the application to depend on "an implementation of
Log4J" in `module-info` without explicitly specifying which one.
If using different module names for each implementation, then when the
application developer writes the `module-info.java` file, they are picking an
explicit implementation of the API, which can't be changed at deploy time as it
would be locked into a `.class` file.
My gut feeling is that the former (same module name for all implementations) is
correct from a modular point of view, however developers would certainly find
it surprising initially because its not how maven artifacts work. Really we
could do with hearing an OSGi/JBoss modules viewpoint on the choice.
Anyway take a look at the link and see what you think -
https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs/_edit
> Modularize Log4j as automatic modules
> -------------------------------------
>
> Key: LOG4J2-2056
> URL: https://issues.apache.org/jira/browse/LOG4J2-2056
> Project: Log4j 2
> Issue Type: New Feature
> Affects Versions: 2.9.1
> Reporter: Ralph Goers
> Assignee: Ralph Goers
>
> To fully support Java 9 all Log4j jars must (at least) be packaged as
> automatic modules. We should, as much as possible, follow the recommendations
> at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given
> that the module names would be:
> ||Jar name||Module name||
> |log4j-api|org.apache.logging.log4j|
> |log4j-core|org.apache.logging.log4j.core|
> |log4j-1.2-api|org.apache.log4j|
> |log4j-appserver|org.apache.logging.log4j.appserver|
> |log4j-flume-ng|org.apache.logging.log4j.flume|
> |log4j-iostreams|org.apache.logging.log4j.iostreams|
> |log4j-jcl|org.apache.logging.log4j.jcl|
> |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
> |log4j-jul|org.apache.logging.log4j.jul|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |log4j-osgi|org.apache.logging.log4j.osgi|
> |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
> |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
> |log4j-taglib|org.apache.logging.log4j.taglib|
> |log4j-web|org.apache.logging.log4j.web|
> # log4j-liquibase uses a package name outside the org.apache.logging.log4j
> namespace so is not modularized.
> # log4j-slf4j-impl cannot currently be modularized until the binding is
> modified. It cannot have classes in the org.slf4j namespace.
> # log4j-slf4j-impl and log4j-to-slf4j both use the same package name -
> org.apache.logging.log4j.slf4j. This will remain the same as it will prevent
> them both from being loaded at the same time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
