[
https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18951#comment-18951
]
Ceki Gülcü commented on SLF4J-407:
----------------------------------
{quote}The argument for the same module name is that only one can be active at
any one time. By using the same module name, it allows the application to
depend on "an implementation of SLF4J" in `module-info` without explicitly
specifying which one.{quote}
Interesting point. In past versions of SLF4J the logging back-end could be
changed by replacing jar files for the back-end. With this version of SLF4J,
i.e version 1.8.0, one would need to recompile the module-info.java file for
the application.
I can think of highly configurable applications such as XWiki that would want
to the end-user to switch logging frameworks via a configuration switch. We
could cater for this use case with a "generic" provider which reads a
configuration parameter and returns the appropriate provider assuming it is
available.
> Jigsaw modules contain clashing package
> ---------------------------------------
>
> Key: SLF4J-407
> URL: https://jira.qos.ch/browse/SLF4J-407
> Project: SLF4J
> Issue Type: Bug
> Components: Implementations
> Affects Versions: 1.8.0-alpha2
> Reporter: Stephen Colebourne
> Assignee: Ceki Gülcü
> Fix For: 1.8.0-beta0
>
>
> Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to
> contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules
> that contain the same package, so this will be a problem.
> I know that SLF4J does not intend users to load both of these modules at the
> same time. But the current setup means that it will be the JPMS runtime that
> rejects it, meaning that there is no chance for SLF4J to output a helpful
> message (as I believe it does today).
> The solution to this would appear to be to move the `org.slf4j.impl` package
> to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not
> exported, this should not affect any user code (except code that would have
> been affected anyway).
> I imagine this affects other slf4j artifacts.
> I also note that [this
> module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-jdk14/src/main/java/module-info.java]
> exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop
> do not export their package).
> See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for
> more information on naming.
--
This message was sent by Atlassian JIRA
(v7.3.1#73012)
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
