[
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198885#comment-16198885
]
Ralph Goers commented on LOG4J2-2056:
-------------------------------------
[~scolebou...@joda.org] Wow - Thanks for taking the time to do that! It is
extremely helpful. I do have a few comments and questions:
# For jars that don't make sense to modularize what would happen if the
Automatic-Module-Name in the jar manifest is no value? We have the jar manifest
specified in the parent pom so adding the Automatic-Module-Name header there
with a variable that each module replaces works well, except for the jars that
won't be modules. From what I can tell module finder would have a problem with
that, but in a way that seems better than having it load it as a module using
the jar's file name.
# Option 1 of the Log4j 2 implementations would change how the Log4j 2 API
binds to its implementation. It currently uses ServiceLoader and loads all
implementations of the service it finds. Right now it only chooses one of them
but it is theoretically possible that it could allow more than one logging
implementation. If we went this route though, it would make me wonder if we
shouldn't use ModuleFinder to locate the implementation module and then bind to
only that implementation. That would be similar to how OSGi works.
# I can't really select Option 1 of the SLF4J implementations without knowing
what Logback is going to do. It would be strange for log4j-slf4j-impl to be
named org.slf4j.impl while Logback is named something else. While it would be
appropriate to think of lgo4j-slf4j-impl as an SLF4J implementation it would
not be appropriate to think of it as a replacement of Logback.
> 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)
