You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2017/09/24 10:33:00 UTC

[jira] [Comment Edited] (LOG4J2-2056) Modularize Log4j as automatic modules

    [ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178143#comment-16178143 ] 

Ralph Goers edited comment on LOG4J2-2056 at 9/24/17 10:32 AM:
---------------------------------------------------------------

If they want to release Log4J 1 then they would use the same module name. That is exactly the point. SLF4J also provides a replacement for Log4J 1.x and it would use the same module name. Only one instance of the module can be present.

It doesn’t really matter whether it is toslf4j or to.slf4j. Neither one matches the package name being used, but in this case I think that is ok. 



was (Author: ralph.goers@dslextreme.com):
If they want to release Log4J 1 then they would use the same module name. That is exactly the point.

It doesn’t really matter whether it is toslf4j or to.slf4j. Neither one matches the package name being used, but in this case I think that is ok. 


> 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.toslf4j|
> |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)