[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16179640#comment-16179640
]
Stephen Colebourne commented on LOG4J2-2056:
--------------------------------------------
I've had a quick look. The api and log4j1.2 jars seem fine. Not clear why you
are using `org.apache.logging.log4j.impl` and not
`org.apache.logging.log4j.core` for the core jar as that is the package root.
The liquibase package does not correspond to the proposed module name. That
looks like it might not work out. Best to omit the module names until you are
confident they are right.
`log4j-to-slf4j` jar file has a root package of `org.apache.logging.slf4j`. So
that would normally be the module name. Naming modules after the jar file name
is usually wrong.
I've not checked all jar files so there could be other issues...
The weird part about logging is that you sometimes want module names to clash
between the various logging projects. If a jar file implements another
project's API in the package namespace of the other project, then the module
name must match the other project's module name too. Note that this applies
only to APIs, not to implementations that are intended to be hidden and in
another package.
The golden rule is that a package can only be loaded from one module.
> 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.impl|
> |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-liquibase|org.apache.logging.log4j.liquibase|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |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|
> # Notably missing is log4j-osgi. Until OSGi documents how it will support
> Java 9 I see no point in modularizing the OSGi jar.
> # 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)
