You mean we may want to do something like this in the future?
module org.apache.logging.log4j {
exports org.apache.logging.log4j;
exports org.apache.logging.log4j.message;
exports org.apache.logging.log4j.simple;
exports org.apache.logging.log4j.spi;
exports org.apache.logging.log4j.status;
exports org.apache.logging.log4j.util to
org.apache.logging.log4j.impl; // only impl can see util
uses org.apache.logging.log4j.spi.Provider;
}
The util package in log4j-api is actually a mixture of "consider private"
implementation classes and interfaces that are actually public API.
So some refactoring will be needed as you say.
Question: does it matter what the log4j-core module name is for the above?
Either impl or core would work, no?
If more modules need access, we can expand the list:
exports org.apache.logging.log4j.util to
org.apache.logging.log4j.core, some.external.impl, yet.another.impl;
I notice that the JDK module docs I've seen so far don't suggest the use of
an identical module name to prevent multiple implementations for a service
on the module path. The emphasis is more on detecting dependencies and
encapsulation, rather than preventing misconfiguration.
I wonder if there are other projects that use identical module names to
prevent misconfiguration. Is this a "best practice"?
Remko
On Sun, Oct 15, 2017 at 4:05 PM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> FWIW, I am still torn on whether log4j-core should have a module name of
> org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is
> the second then log4j-api could restrict exporting packages only meant for
> the implementation to that module. That would require some refactoring of
> the API classes but that shouldn’t be too big of a deal. Is the benefit of
> doing that greater than the (hypothetical) benefit of supporting multiple
> log4j implementations at the same time? Should log4j-to-slf4j also then
> use the same module name since it replaces log4j-core?
>
> Ralph
>
> > On Oct 14, 2017, at 10:40 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> >
> > I have committed the code for LOG4J2-2056. Log4j-api is a “real” module
> and has a module-info.java while all the rest that can be modularized are
> automatic modules. Please review and test.
> >
> > In order to create the module-info.java I had to do a few strange things:
> > Module-info.java is in the log4j-api-java9 project since log4j-api isn’t
> compiled with Java 9.
> > Compiling module-info.java requires that the packages being exported
> exist and have at least one class in them, so I had to create the
> directories and place a dummy java class in them.
> > The assembly that creates the log4j-api-java9 zip ignores all the dummy
> files and directories and only copies module-info.java and the two utility
> classes into the zip.
> >
> > I have tested this with a simple program that only uses a module path
> but I would appreciate more extensive tests before it is released.
> >
> > Ralph
>
>
>
