[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202635#comment-16202635
]
Ralph Goers commented on LOG4J2-2056:
-------------------------------------
[~njbartlett] Thanks for jumping in. The options are listed in the link Stephen
created - https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs.
Basically, it is a choice on whether to have multiple modules that implement
the same thing all use the same module name or whether they should all be
unique. SLF4J and the Log4j 2 API can each be bound to one of many logging
implementations. So should Logback use org.slf4j.impl as its module name or
Logback's package - ch.qos.logback. Likewise, Log4j's implementation could
either be org.apache.logging.log4j.impl (a generic name) or
org.apache.logging.log4j.core (the actual package name of the implementation).
In the case of SLF4J, Log4j provides a "binding" that causes SLF4J to use
Log4j. We would either also use org.slf4j.impl for that or we would use
org.apache.logging.log4j.slf4j.
Right now these are all automatic modules - we can't turn them into "real"
modules until all the dependencies have declared names - but we need to have
the names be right on the first try. Unfortunately, JPMS doesn't provide any
guidance on any of this. It is only with the help of folks like you and Stephen
that Java frameworks are making any progress at all.
> 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:
> ||Artifact ID ||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)
