[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202658#comment-16202658
]
Neil Bartlett commented on LOG4J2-2056:
---------------------------------------
Whatever name you choose, that is the name that modules must declare their
requirement on. If a module depends on `org.apache.logging.log4j.slf4j` then it
will be bound to that implementation and cannot use a substitute implementation
such as Logback.
JPMS only provides one mechanism for implementation substitution, and that is
Services. To do this "properly" you would refactor the APIs so that they are
pure interfaces with the implementation provided as a service. Then a consumer
module need only depend on the pure API at build time, so long as an
appropriate implementation is provided at assembly time. It seems unlikely this
scenario can be achieved without breaking backwards compatibility.
So it seems you have two choices. (a) Give each module a unique name, and live
with coupling consumers to a specific implementation, or (b) Give all modules
providing the same API the same module name, and live with the idea that
artifact identity and module identity are decoupled.
> 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)
