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 <ra...@dslextreme.com> on 2021/04/13 15:43:40 UTC
Log4j core
I started doing the work to modularize log4j-core last night. We have a blocker in that the disruptor has not had a release in 3 years. They committed the change to make it an automatic module over a year ago and since have fully modularized it. They simply haven’t performed a release.
As I was going through the module descriptor (see below) it seems to me that we have far more dependencies in core than I would really like. For example, despite moving the Jackson Layouts to their own modules we still have a dependency on Jackson. We also have dependencies on things like java.rmi, java.naming, java.sql. I am also not clear on whether they are all really optional or not. Ideally, the only required dependency we should have is for java.base. For example, we need java.rmi because Log4jLogEvent uses MarshalledObject. I have no idea why we need that particular class to wrap a log event. Couldn’t we have created our own class for that? We need java.desktop because java.beans now lives there. Perhaps we could look at what those are and if it is really just one or two utility methods implement them locally.
In the meantime I have created an issue with the Disruptor asking for a release. I can’t do much more with core until that is available. I can move on to other modules.
We also need to look at the list of exports below and the classes in them and determine what is really public and what should be private.
Thoughts?
Ralph
module org.apache.logging.log4j.core {
exports org.apache.logging.log4j.core;
exports org.apache.logging.log4j.core.appender;
exports org.apache.logging.log4j.core.appender.db;
exports org.apache.logging.log4j.core.appender.nosql;
exports org.apache.logging.log4j.core.appender.rewrite;
exports org.apache.logging.log4j.core.appender.rolling;
exports org.apache.logging.log4j.core.appender.rolling.action;
exports org.apache.logging.log4j.core.appender.routing;
exports org.apache.logging.log4j.core.async;
exports org.apache.logging.log4j.core.config;
exports org.apache.logging.log4j.core.config.arbiters;
exports org.apache.logging.log4j.core.config.builder.api;
exports org.apache.logging.log4j.core.config.builder.impl;
exports org.apache.logging.log4j.core.config.composite;
exports org.apache.logging.log4j.core.config.json;
exports org.apache.logging.log4j.core.config.plugins;
exports org.apache.logging.log4j.core.config.plugins.convert;
exports org.apache.logging.log4j.core.config.plugins.inject;
exports org.apache.logging.log4j.core.config.plugins.util;
exports org.apache.logging.log4j.core.config.plugins.visitors;
exports org.apache.logging.log4j.core.config.properties;
exports org.apache.logging.log4j.core.config.status;
exports org.apache.logging.log4j.core.config.xml;
exports org.apache.logging.log4j.core.config.yaml;
exports org.apache.logging.log4j.core.filter;
exports org.apache.logging.log4j.core.impl;
exports org.apache.logging.log4j.core.jmx;
exports org.apache.logging.log4j.core.layout;
exports org.apache.logging.log4j.core.lookup;
exports org.apache.logging.log4j.core.message;
exports org.apache.logging.log4j.core.net;
exports org.apache.logging.log4j.core.net.ssl;
exports org.apache.logging.log4j.core.osgi;
exports org.apache.logging.log4j.core.parser;
exports org.apache.logging.log4j.core.pattern;
exports org.apache.logging.log4j.core.script;
exports org.apache.logging.log4j.core.selector;
exports org.apache.logging.log4j.core.time;
exports org.apache.logging.log4j.core.tools;
exports org.apache.logging.log4j.core.tools.picocli;
exports org.apache.logging.log4j.core.util;
exports org.apache.logging.log4j.core.util.datetime;
requires transitive java.desktop;
requires transitive java.management;
requires java.naming;
requires transitive java.sql;
requires java.rmi;
requires transitive java.scripting;
requires java.xml;
requires org.apache.logging.log4j;
requires org.apache.logging.log4j.plugins;
//requires transitive com.lmax.distruptor;
requires transitive org.osgi.core;
requires transitive com.conversantmedia.disruptor;
requires transitive com.fasterxml.jackson.core;
requires transitive com.fasterxml.jackson.databind;
requires transitive com.fasterxml.jackson.dataformat.xml;
requires transitive com.fasterxml.jackson.dataformat.yaml;
requires transitive org.apache.commons.compress;
requires transitive org.fusesource.jansi;
uses org.apache.logging.log4j.core.util.ContextDataProvider;
provides org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
provides org.apache.logging.log4j.core.util.ContextDataProvider with org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
provides org.apache.logging.log4j.spi.Provider with org.apache.logging.log4j.core.impl.Log4jProvider;
provides org.apache.logging.log4j.plugins.processor.PluginService with org.apache.logging.log4j.core.plugins.Log4jPlugins;
Re: Log4j core
Posted by Ralph Goers <ra...@dslextreme.com>.
That is what is concerning. A lot of those items have already been moved to their own modules in master. Yet we still have these dependencies.
Ralph
> On Apr 13, 2021, at 10:53 AM, Jochen Wiedmann <jo...@gmail.com> wrote:
>
> On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers <ra...@dslextreme.com> wrote:
>
>> We also have dependencies on things like java.rmi, java.naming, java.sql. I am also not clear on whether they are all really optional or not. Ideally, the only required dependency we should have is for java.base.
>
> Most likely, those dependencies are related to specific appenders,
> like, the JDBCAppender, and similar stuff. This could be resolved by
>
> a) Moving those appenders to separately distributable, and
> optional, modules, and
> b) Enhance the plugin mechanism to detect, and (if necessary)
> initialize such modules automatically,
>
> As a result, we could have a core, which behaves just like before, if
> those modules are present in the classpath.
>
> Jochen
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
Re: Log4j core
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers <ra...@dslextreme.com> wrote:
> We also have dependencies on things like java.rmi, java.naming, java.sql. I am also not clear on whether they are all really optional or not. Ideally, the only required dependency we should have is for java.base.
Most likely, those dependencies are related to specific appenders,
like, the JDBCAppender, and similar stuff. This could be resolved by
a) Moving those appenders to separately distributable, and
optional, modules, and
b) Enhance the plugin mechanism to detect, and (if necessary)
initialize such modules automatically,
As a result, we could have a core, which behaves just like before, if
those modules are present in the classpath.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
Re: Log4j core
Posted by Remko Popma <re...@gmail.com>.
On Wed, Apr 14, 2021 at 1:41 AM Matt Sicker <bo...@gmail.com> wrote:
> The picocli reference is likely for type conversion. Possibly removable.
>
Agreed, yes.
Actually, weren't picocli and all CLI tools moved to log4j-tools or
log4j-server or something?
> On Tue, 13 Apr 2021 at 11:34, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > I just got an email reply to the issue I created for the Disruptor. They
> created a release this morning with the automatic module name so I should
> be able to pick that up fairly soon.
> >
> >
> /Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/tools/picocli/CommandLine.java:[41,11]
> error: package java.sql is not visible
> >
> > This indicates java.sql is needed for Picocli. Why?
> >
> > It seems JNDI is needed for JndiLookup and JndiContextSelector. Those
> could be moved to another module if we want.
> >
> > The Scripting stuff might also be able to moved to a separate module. I
> will have to look into that. AbstractConfiguration references the
> ScriptManager but that module could be built before core and then could be
> optional.
> >
> > Ralph
> >
> > > On Apr 13, 2021, at 9:17 AM, Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > The SQL code is all related to JDBC and related appenders which could
> go in
> > > their own module. The naming is primarily used for EE stuff which
> could all
> > > be split out (plus, I don’t think it’s in the default Android variant
> of
> > > Java). The RMI thing can probably be replaced as you suggested.
> > > JMX/management might have some overlap there? As for the beans package,
> > > that can also be replaced with code instead of linking in that module.
> > >
> > > The interesting ones look to be XML and scripting as those are fairly
> > > useful core features, but they could be in their own modules. That
> would
> > > likely leave core such that it only supports programmatic
> configuration and
> > > properties files since every other format requires additional modules
> > > besides base.
> > >
> > > As for exports, that would likely depend on what’s left in core after
> > > splitting out the above mentioned things.
> > >
> > > On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
> > > wrote:
> > >
> > >> I started doing the work to modularize log4j-core last night. We have
> a
> > >> blocker in that the disruptor has not had a release in 3 years. They
> > >> committed the change to make it an automatic module over a year ago
> and
> > >> since have fully modularized it. They simply haven’t performed a
> release.
> > >>
> > >> As I was going through the module descriptor (see below) it seems to
> me
> > >> that we have far more dependencies in core than I would really like.
> For
> > >> example, despite moving the Jackson Layouts to their own modules we
> still
> > >> have a dependency on Jackson. We also have dependencies on things like
> > >> java.rmi, java.naming, java.sql. I am also not clear on whether they
> are
> > >> all really optional or not. Ideally, the only required dependency we
> should
> > >> have is for java.base. For example, we need java.rmi because
> Log4jLogEvent
> > >> uses MarshalledObject. I have no idea why we need that particular
> class to
> > >> wrap a log event. Couldn’t we have created our own class for that? We
> need
> > >> java.desktop because java.beans now lives there. Perhaps we could
> look at
> > >> what those are and if it is really just one or two utility methods
> > >> implement them locally.
> > >>
> > >> In the meantime I have created an issue with the Disruptor asking for
> a
> > >> release. I can’t do much more with core until that is available. I
> can move
> > >> on to other modules.
> > >>
> > >> We also need to look at the list of exports below and the classes in
> them
> > >> and determine what is really public and what should be private.
> > >>
> > >>
> > >> Thoughts?
> > >>
> > >> Ralph
> > >>
> > >>
> > >> module org.apache.logging.log4j.core {
> > >> exports org.apache.logging.log4j.core;
> > >> exports org.apache.logging.log4j.core.appender;
> > >> exports org.apache.logging.log4j.core.appender.db;
> > >> exports org.apache.logging.log4j.core.appender.nosql;
> > >> exports org.apache.logging.log4j.core.appender.rewrite;
> > >> exports org.apache.logging.log4j.core.appender.rolling;
> > >> exports org.apache.logging.log4j.core.appender.rolling.action;
> > >> exports org.apache.logging.log4j.core.appender.routing;
> > >> exports org.apache.logging.log4j.core.async;
> > >> exports org.apache.logging.log4j.core.config;
> > >> exports org.apache.logging.log4j.core.config.arbiters;
> > >> exports org.apache.logging.log4j.core.config.builder.api;
> > >> exports org.apache.logging.log4j.core.config.builder.impl;
> > >> exports org.apache.logging.log4j.core.config.composite;
> > >> exports org.apache.logging.log4j.core.config.json;
> > >> exports org.apache.logging.log4j.core.config.plugins;
> > >> exports org.apache.logging.log4j.core.config.plugins.convert;
> > >> exports org.apache.logging.log4j.core.config.plugins.inject;
> > >> exports org.apache.logging.log4j.core.config.plugins.util;
> > >> exports org.apache.logging.log4j.core.config.plugins.visitors;
> > >> exports org.apache.logging.log4j.core.config.properties;
> > >> exports org.apache.logging.log4j.core.config.status;
> > >> exports org.apache.logging.log4j.core.config.xml;
> > >> exports org.apache.logging.log4j.core.config.yaml;
> > >> exports org.apache.logging.log4j.core.filter;
> > >> exports org.apache.logging.log4j.core.impl;
> > >> exports org.apache.logging.log4j.core.jmx;
> > >> exports org.apache.logging.log4j.core.layout;
> > >> exports org.apache.logging.log4j.core.lookup;
> > >> exports org.apache.logging.log4j.core.message;
> > >> exports org.apache.logging.log4j.core.net;
> > >> exports org.apache.logging.log4j.core.net.ssl;
> > >> exports org.apache.logging.log4j.core.osgi;
> > >> exports org.apache.logging.log4j.core.parser;
> > >> exports org.apache.logging.log4j.core.pattern;
> > >> exports org.apache.logging.log4j.core.script;
> > >> exports org.apache.logging.log4j.core.selector;
> > >> exports org.apache.logging.log4j.core.time;
> > >> exports org.apache.logging.log4j.core.tools;
> > >> exports org.apache.logging.log4j.core.tools.picocli;
> > >> exports org.apache.logging.log4j.core.util;
> > >> exports org.apache.logging.log4j.core.util.datetime;
> > >>
> > >> requires transitive java.desktop;
> > >> requires transitive java.management;
> > >> requires java.naming;
> > >> requires transitive java.sql;
> > >> requires java.rmi;
> > >> requires transitive java.scripting;
> > >> requires java.xml;
> > >> requires org.apache.logging.log4j;
> > >> requires org.apache.logging.log4j.plugins;
> > >> //requires transitive com.lmax.distruptor;
> > >> requires transitive org.osgi.core;
> > >> requires transitive com.conversantmedia.disruptor;
> > >> requires transitive com.fasterxml.jackson.core;
> > >> requires transitive com.fasterxml.jackson.databind;
> > >> requires transitive com.fasterxml.jackson.dataformat.xml;
> > >> requires transitive com.fasterxml.jackson.dataformat.yaml;
> > >> requires transitive org.apache.commons.compress;
> > >> requires transitive org.fusesource.jansi;
> > >> uses org.apache.logging.log4j.core.util.ContextDataProvider;
> > >> provides
> > >> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory
> with
> > >> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
> > >> provides org.apache.logging.log4j.core.util.ContextDataProvider
> with
> > >> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
> > >> provides org.apache.logging.log4j.spi.Provider with
> > >> org.apache.logging.log4j.core.impl.Log4jProvider;
> > >> provides org.apache.logging.log4j.plugins.processor.PluginService
> with
> > >> org.apache.logging.log4j.core.plugins.Log4jPlugins;
> > >>
> > >>
> >
> >
>
Re: Log4j core
Posted by Matt Sicker <bo...@gmail.com>.
The picocli reference is likely for type conversion. Possibly removable.
On Tue, 13 Apr 2021 at 11:34, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I just got an email reply to the issue I created for the Disruptor. They created a release this morning with the automatic module name so I should be able to pick that up fairly soon.
>
> /Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/tools/picocli/CommandLine.java:[41,11] error: package java.sql is not visible
>
> This indicates java.sql is needed for Picocli. Why?
>
> It seems JNDI is needed for JndiLookup and JndiContextSelector. Those could be moved to another module if we want.
>
> The Scripting stuff might also be able to moved to a separate module. I will have to look into that. AbstractConfiguration references the ScriptManager but that module could be built before core and then could be optional.
>
> Ralph
>
> > On Apr 13, 2021, at 9:17 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > The SQL code is all related to JDBC and related appenders which could go in
> > their own module. The naming is primarily used for EE stuff which could all
> > be split out (plus, I don’t think it’s in the default Android variant of
> > Java). The RMI thing can probably be replaced as you suggested.
> > JMX/management might have some overlap there? As for the beans package,
> > that can also be replaced with code instead of linking in that module.
> >
> > The interesting ones look to be XML and scripting as those are fairly
> > useful core features, but they could be in their own modules. That would
> > likely leave core such that it only supports programmatic configuration and
> > properties files since every other format requires additional modules
> > besides base.
> >
> > As for exports, that would likely depend on what’s left in core after
> > splitting out the above mentioned things.
> >
> > On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> I started doing the work to modularize log4j-core last night. We have a
> >> blocker in that the disruptor has not had a release in 3 years. They
> >> committed the change to make it an automatic module over a year ago and
> >> since have fully modularized it. They simply haven’t performed a release.
> >>
> >> As I was going through the module descriptor (see below) it seems to me
> >> that we have far more dependencies in core than I would really like. For
> >> example, despite moving the Jackson Layouts to their own modules we still
> >> have a dependency on Jackson. We also have dependencies on things like
> >> java.rmi, java.naming, java.sql. I am also not clear on whether they are
> >> all really optional or not. Ideally, the only required dependency we should
> >> have is for java.base. For example, we need java.rmi because Log4jLogEvent
> >> uses MarshalledObject. I have no idea why we need that particular class to
> >> wrap a log event. Couldn’t we have created our own class for that? We need
> >> java.desktop because java.beans now lives there. Perhaps we could look at
> >> what those are and if it is really just one or two utility methods
> >> implement them locally.
> >>
> >> In the meantime I have created an issue with the Disruptor asking for a
> >> release. I can’t do much more with core until that is available. I can move
> >> on to other modules.
> >>
> >> We also need to look at the list of exports below and the classes in them
> >> and determine what is really public and what should be private.
> >>
> >>
> >> Thoughts?
> >>
> >> Ralph
> >>
> >>
> >> module org.apache.logging.log4j.core {
> >> exports org.apache.logging.log4j.core;
> >> exports org.apache.logging.log4j.core.appender;
> >> exports org.apache.logging.log4j.core.appender.db;
> >> exports org.apache.logging.log4j.core.appender.nosql;
> >> exports org.apache.logging.log4j.core.appender.rewrite;
> >> exports org.apache.logging.log4j.core.appender.rolling;
> >> exports org.apache.logging.log4j.core.appender.rolling.action;
> >> exports org.apache.logging.log4j.core.appender.routing;
> >> exports org.apache.logging.log4j.core.async;
> >> exports org.apache.logging.log4j.core.config;
> >> exports org.apache.logging.log4j.core.config.arbiters;
> >> exports org.apache.logging.log4j.core.config.builder.api;
> >> exports org.apache.logging.log4j.core.config.builder.impl;
> >> exports org.apache.logging.log4j.core.config.composite;
> >> exports org.apache.logging.log4j.core.config.json;
> >> exports org.apache.logging.log4j.core.config.plugins;
> >> exports org.apache.logging.log4j.core.config.plugins.convert;
> >> exports org.apache.logging.log4j.core.config.plugins.inject;
> >> exports org.apache.logging.log4j.core.config.plugins.util;
> >> exports org.apache.logging.log4j.core.config.plugins.visitors;
> >> exports org.apache.logging.log4j.core.config.properties;
> >> exports org.apache.logging.log4j.core.config.status;
> >> exports org.apache.logging.log4j.core.config.xml;
> >> exports org.apache.logging.log4j.core.config.yaml;
> >> exports org.apache.logging.log4j.core.filter;
> >> exports org.apache.logging.log4j.core.impl;
> >> exports org.apache.logging.log4j.core.jmx;
> >> exports org.apache.logging.log4j.core.layout;
> >> exports org.apache.logging.log4j.core.lookup;
> >> exports org.apache.logging.log4j.core.message;
> >> exports org.apache.logging.log4j.core.net;
> >> exports org.apache.logging.log4j.core.net.ssl;
> >> exports org.apache.logging.log4j.core.osgi;
> >> exports org.apache.logging.log4j.core.parser;
> >> exports org.apache.logging.log4j.core.pattern;
> >> exports org.apache.logging.log4j.core.script;
> >> exports org.apache.logging.log4j.core.selector;
> >> exports org.apache.logging.log4j.core.time;
> >> exports org.apache.logging.log4j.core.tools;
> >> exports org.apache.logging.log4j.core.tools.picocli;
> >> exports org.apache.logging.log4j.core.util;
> >> exports org.apache.logging.log4j.core.util.datetime;
> >>
> >> requires transitive java.desktop;
> >> requires transitive java.management;
> >> requires java.naming;
> >> requires transitive java.sql;
> >> requires java.rmi;
> >> requires transitive java.scripting;
> >> requires java.xml;
> >> requires org.apache.logging.log4j;
> >> requires org.apache.logging.log4j.plugins;
> >> //requires transitive com.lmax.distruptor;
> >> requires transitive org.osgi.core;
> >> requires transitive com.conversantmedia.disruptor;
> >> requires transitive com.fasterxml.jackson.core;
> >> requires transitive com.fasterxml.jackson.databind;
> >> requires transitive com.fasterxml.jackson.dataformat.xml;
> >> requires transitive com.fasterxml.jackson.dataformat.yaml;
> >> requires transitive org.apache.commons.compress;
> >> requires transitive org.fusesource.jansi;
> >> uses org.apache.logging.log4j.core.util.ContextDataProvider;
> >> provides
> >> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
> >> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
> >> provides org.apache.logging.log4j.core.util.ContextDataProvider with
> >> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
> >> provides org.apache.logging.log4j.spi.Provider with
> >> org.apache.logging.log4j.core.impl.Log4jProvider;
> >> provides org.apache.logging.log4j.plugins.processor.PluginService with
> >> org.apache.logging.log4j.core.plugins.Log4jPlugins;
> >>
> >>
>
>
Re: Log4j core
Posted by Ralph Goers <ra...@dslextreme.com>.
I just got an email reply to the issue I created for the Disruptor. They created a release this morning with the automatic module name so I should be able to pick that up fairly soon.
/Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/tools/picocli/CommandLine.java:[41,11] error: package java.sql is not visible
This indicates java.sql is needed for Picocli. Why?
It seems JNDI is needed for JndiLookup and JndiContextSelector. Those could be moved to another module if we want.
The Scripting stuff might also be able to moved to a separate module. I will have to look into that. AbstractConfiguration references the ScriptManager but that module could be built before core and then could be optional.
Ralph
> On Apr 13, 2021, at 9:17 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> The SQL code is all related to JDBC and related appenders which could go in
> their own module. The naming is primarily used for EE stuff which could all
> be split out (plus, I don’t think it’s in the default Android variant of
> Java). The RMI thing can probably be replaced as you suggested.
> JMX/management might have some overlap there? As for the beans package,
> that can also be replaced with code instead of linking in that module.
>
> The interesting ones look to be XML and scripting as those are fairly
> useful core features, but they could be in their own modules. That would
> likely leave core such that it only supports programmatic configuration and
> properties files since every other format requires additional modules
> besides base.
>
> As for exports, that would likely depend on what’s left in core after
> splitting out the above mentioned things.
>
> On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I started doing the work to modularize log4j-core last night. We have a
>> blocker in that the disruptor has not had a release in 3 years. They
>> committed the change to make it an automatic module over a year ago and
>> since have fully modularized it. They simply haven’t performed a release.
>>
>> As I was going through the module descriptor (see below) it seems to me
>> that we have far more dependencies in core than I would really like. For
>> example, despite moving the Jackson Layouts to their own modules we still
>> have a dependency on Jackson. We also have dependencies on things like
>> java.rmi, java.naming, java.sql. I am also not clear on whether they are
>> all really optional or not. Ideally, the only required dependency we should
>> have is for java.base. For example, we need java.rmi because Log4jLogEvent
>> uses MarshalledObject. I have no idea why we need that particular class to
>> wrap a log event. Couldn’t we have created our own class for that? We need
>> java.desktop because java.beans now lives there. Perhaps we could look at
>> what those are and if it is really just one or two utility methods
>> implement them locally.
>>
>> In the meantime I have created an issue with the Disruptor asking for a
>> release. I can’t do much more with core until that is available. I can move
>> on to other modules.
>>
>> We also need to look at the list of exports below and the classes in them
>> and determine what is really public and what should be private.
>>
>>
>> Thoughts?
>>
>> Ralph
>>
>>
>> module org.apache.logging.log4j.core {
>> exports org.apache.logging.log4j.core;
>> exports org.apache.logging.log4j.core.appender;
>> exports org.apache.logging.log4j.core.appender.db;
>> exports org.apache.logging.log4j.core.appender.nosql;
>> exports org.apache.logging.log4j.core.appender.rewrite;
>> exports org.apache.logging.log4j.core.appender.rolling;
>> exports org.apache.logging.log4j.core.appender.rolling.action;
>> exports org.apache.logging.log4j.core.appender.routing;
>> exports org.apache.logging.log4j.core.async;
>> exports org.apache.logging.log4j.core.config;
>> exports org.apache.logging.log4j.core.config.arbiters;
>> exports org.apache.logging.log4j.core.config.builder.api;
>> exports org.apache.logging.log4j.core.config.builder.impl;
>> exports org.apache.logging.log4j.core.config.composite;
>> exports org.apache.logging.log4j.core.config.json;
>> exports org.apache.logging.log4j.core.config.plugins;
>> exports org.apache.logging.log4j.core.config.plugins.convert;
>> exports org.apache.logging.log4j.core.config.plugins.inject;
>> exports org.apache.logging.log4j.core.config.plugins.util;
>> exports org.apache.logging.log4j.core.config.plugins.visitors;
>> exports org.apache.logging.log4j.core.config.properties;
>> exports org.apache.logging.log4j.core.config.status;
>> exports org.apache.logging.log4j.core.config.xml;
>> exports org.apache.logging.log4j.core.config.yaml;
>> exports org.apache.logging.log4j.core.filter;
>> exports org.apache.logging.log4j.core.impl;
>> exports org.apache.logging.log4j.core.jmx;
>> exports org.apache.logging.log4j.core.layout;
>> exports org.apache.logging.log4j.core.lookup;
>> exports org.apache.logging.log4j.core.message;
>> exports org.apache.logging.log4j.core.net;
>> exports org.apache.logging.log4j.core.net.ssl;
>> exports org.apache.logging.log4j.core.osgi;
>> exports org.apache.logging.log4j.core.parser;
>> exports org.apache.logging.log4j.core.pattern;
>> exports org.apache.logging.log4j.core.script;
>> exports org.apache.logging.log4j.core.selector;
>> exports org.apache.logging.log4j.core.time;
>> exports org.apache.logging.log4j.core.tools;
>> exports org.apache.logging.log4j.core.tools.picocli;
>> exports org.apache.logging.log4j.core.util;
>> exports org.apache.logging.log4j.core.util.datetime;
>>
>> requires transitive java.desktop;
>> requires transitive java.management;
>> requires java.naming;
>> requires transitive java.sql;
>> requires java.rmi;
>> requires transitive java.scripting;
>> requires java.xml;
>> requires org.apache.logging.log4j;
>> requires org.apache.logging.log4j.plugins;
>> //requires transitive com.lmax.distruptor;
>> requires transitive org.osgi.core;
>> requires transitive com.conversantmedia.disruptor;
>> requires transitive com.fasterxml.jackson.core;
>> requires transitive com.fasterxml.jackson.databind;
>> requires transitive com.fasterxml.jackson.dataformat.xml;
>> requires transitive com.fasterxml.jackson.dataformat.yaml;
>> requires transitive org.apache.commons.compress;
>> requires transitive org.fusesource.jansi;
>> uses org.apache.logging.log4j.core.util.ContextDataProvider;
>> provides
>> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
>> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
>> provides org.apache.logging.log4j.core.util.ContextDataProvider with
>> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
>> provides org.apache.logging.log4j.spi.Provider with
>> org.apache.logging.log4j.core.impl.Log4jProvider;
>> provides org.apache.logging.log4j.plugins.processor.PluginService with
>> org.apache.logging.log4j.core.plugins.Log4jPlugins;
>>
>>
Re: Log4j core
Posted by Ralph Goers <ra...@dslextreme.com>.
You did. But we still have stuff using the dependencies.
Ralph
> On Apr 13, 2021, at 12:05 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> I thought I already did a lot of that moving around of code to new modules
> in master a long time ago, I might be remembering wrong, AFK ATM.
>
> Gary
>
> On Tue, Apr 13, 2021, 12:17 Matt Sicker <bo...@gmail.com> wrote:
>
>> The SQL code is all related to JDBC and related appenders which could go in
>> their own module. The naming is primarily used for EE stuff which could all
>> be split out (plus, I don’t think it’s in the default Android variant of
>> Java). The RMI thing can probably be replaced as you suggested.
>> JMX/management might have some overlap there? As for the beans package,
>> that can also be replaced with code instead of linking in that module.
>>
>> The interesting ones look to be XML and scripting as those are fairly
>> useful core features, but they could be in their own modules. That would
>> likely leave core such that it only supports programmatic configuration and
>> properties files since every other format requires additional modules
>> besides base.
>>
>> As for exports, that would likely depend on what’s left in core after
>> splitting out the above mentioned things.
>>
>> On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> I started doing the work to modularize log4j-core last night. We have a
>>> blocker in that the disruptor has not had a release in 3 years. They
>>> committed the change to make it an automatic module over a year ago and
>>> since have fully modularized it. They simply haven’t performed a release.
>>>
>>> As I was going through the module descriptor (see below) it seems to me
>>> that we have far more dependencies in core than I would really like. For
>>> example, despite moving the Jackson Layouts to their own modules we still
>>> have a dependency on Jackson. We also have dependencies on things like
>>> java.rmi, java.naming, java.sql. I am also not clear on whether they are
>>> all really optional or not. Ideally, the only required dependency we
>> should
>>> have is for java.base. For example, we need java.rmi because
>> Log4jLogEvent
>>> uses MarshalledObject. I have no idea why we need that particular class
>> to
>>> wrap a log event. Couldn’t we have created our own class for that? We
>> need
>>> java.desktop because java.beans now lives there. Perhaps we could look at
>>> what those are and if it is really just one or two utility methods
>>> implement them locally.
>>>
>>> In the meantime I have created an issue with the Disruptor asking for a
>>> release. I can’t do much more with core until that is available. I can
>> move
>>> on to other modules.
>>>
>>> We also need to look at the list of exports below and the classes in them
>>> and determine what is really public and what should be private.
>>>
>>>
>>> Thoughts?
>>>
>>> Ralph
>>>
>>>
>>> module org.apache.logging.log4j.core {
>>> exports org.apache.logging.log4j.core;
>>> exports org.apache.logging.log4j.core.appender;
>>> exports org.apache.logging.log4j.core.appender.db;
>>> exports org.apache.logging.log4j.core.appender.nosql;
>>> exports org.apache.logging.log4j.core.appender.rewrite;
>>> exports org.apache.logging.log4j.core.appender.rolling;
>>> exports org.apache.logging.log4j.core.appender.rolling.action;
>>> exports org.apache.logging.log4j.core.appender.routing;
>>> exports org.apache.logging.log4j.core.async;
>>> exports org.apache.logging.log4j.core.config;
>>> exports org.apache.logging.log4j.core.config.arbiters;
>>> exports org.apache.logging.log4j.core.config.builder.api;
>>> exports org.apache.logging.log4j.core.config.builder.impl;
>>> exports org.apache.logging.log4j.core.config.composite;
>>> exports org.apache.logging.log4j.core.config.json;
>>> exports org.apache.logging.log4j.core.config.plugins;
>>> exports org.apache.logging.log4j.core.config.plugins.convert;
>>> exports org.apache.logging.log4j.core.config.plugins.inject;
>>> exports org.apache.logging.log4j.core.config.plugins.util;
>>> exports org.apache.logging.log4j.core.config.plugins.visitors;
>>> exports org.apache.logging.log4j.core.config.properties;
>>> exports org.apache.logging.log4j.core.config.status;
>>> exports org.apache.logging.log4j.core.config.xml;
>>> exports org.apache.logging.log4j.core.config.yaml;
>>> exports org.apache.logging.log4j.core.filter;
>>> exports org.apache.logging.log4j.core.impl;
>>> exports org.apache.logging.log4j.core.jmx;
>>> exports org.apache.logging.log4j.core.layout;
>>> exports org.apache.logging.log4j.core.lookup;
>>> exports org.apache.logging.log4j.core.message;
>>> exports org.apache.logging.log4j.core.net;
>>> exports org.apache.logging.log4j.core.net.ssl;
>>> exports org.apache.logging.log4j.core.osgi;
>>> exports org.apache.logging.log4j.core.parser;
>>> exports org.apache.logging.log4j.core.pattern;
>>> exports org.apache.logging.log4j.core.script;
>>> exports org.apache.logging.log4j.core.selector;
>>> exports org.apache.logging.log4j.core.time;
>>> exports org.apache.logging.log4j.core.tools;
>>> exports org.apache.logging.log4j.core.tools.picocli;
>>> exports org.apache.logging.log4j.core.util;
>>> exports org.apache.logging.log4j.core.util.datetime;
>>>
>>> requires transitive java.desktop;
>>> requires transitive java.management;
>>> requires java.naming;
>>> requires transitive java.sql;
>>> requires java.rmi;
>>> requires transitive java.scripting;
>>> requires java.xml;
>>> requires org.apache.logging.log4j;
>>> requires org.apache.logging.log4j.plugins;
>>> //requires transitive com.lmax.distruptor;
>>> requires transitive org.osgi.core;
>>> requires transitive com.conversantmedia.disruptor;
>>> requires transitive com.fasterxml.jackson.core;
>>> requires transitive com.fasterxml.jackson.databind;
>>> requires transitive com.fasterxml.jackson.dataformat.xml;
>>> requires transitive com.fasterxml.jackson.dataformat.yaml;
>>> requires transitive org.apache.commons.compress;
>>> requires transitive org.fusesource.jansi;
>>> uses org.apache.logging.log4j.core.util.ContextDataProvider;
>>> provides
>>> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
>>> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
>>> provides org.apache.logging.log4j.core.util.ContextDataProvider with
>>> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
>>> provides org.apache.logging.log4j.spi.Provider with
>>> org.apache.logging.log4j.core.impl.Log4jProvider;
>>> provides org.apache.logging.log4j.plugins.processor.PluginService
>> with
>>> org.apache.logging.log4j.core.plugins.Log4jPlugins;
>>>
>>>
>>
Re: Log4j core
Posted by Gary Gregory <ga...@gmail.com>.
I thought I already did a lot of that moving around of code to new modules
in master a long time ago, I might be remembering wrong, AFK ATM.
Gary
On Tue, Apr 13, 2021, 12:17 Matt Sicker <bo...@gmail.com> wrote:
> The SQL code is all related to JDBC and related appenders which could go in
> their own module. The naming is primarily used for EE stuff which could all
> be split out (plus, I don’t think it’s in the default Android variant of
> Java). The RMI thing can probably be replaced as you suggested.
> JMX/management might have some overlap there? As for the beans package,
> that can also be replaced with code instead of linking in that module.
>
> The interesting ones look to be XML and scripting as those are fairly
> useful core features, but they could be in their own modules. That would
> likely leave core such that it only supports programmatic configuration and
> properties files since every other format requires additional modules
> besides base.
>
> As for exports, that would likely depend on what’s left in core after
> splitting out the above mentioned things.
>
> On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > I started doing the work to modularize log4j-core last night. We have a
> > blocker in that the disruptor has not had a release in 3 years. They
> > committed the change to make it an automatic module over a year ago and
> > since have fully modularized it. They simply haven’t performed a release.
> >
> > As I was going through the module descriptor (see below) it seems to me
> > that we have far more dependencies in core than I would really like. For
> > example, despite moving the Jackson Layouts to their own modules we still
> > have a dependency on Jackson. We also have dependencies on things like
> > java.rmi, java.naming, java.sql. I am also not clear on whether they are
> > all really optional or not. Ideally, the only required dependency we
> should
> > have is for java.base. For example, we need java.rmi because
> Log4jLogEvent
> > uses MarshalledObject. I have no idea why we need that particular class
> to
> > wrap a log event. Couldn’t we have created our own class for that? We
> need
> > java.desktop because java.beans now lives there. Perhaps we could look at
> > what those are and if it is really just one or two utility methods
> > implement them locally.
> >
> > In the meantime I have created an issue with the Disruptor asking for a
> > release. I can’t do much more with core until that is available. I can
> move
> > on to other modules.
> >
> > We also need to look at the list of exports below and the classes in them
> > and determine what is really public and what should be private.
> >
> >
> > Thoughts?
> >
> > Ralph
> >
> >
> > module org.apache.logging.log4j.core {
> > exports org.apache.logging.log4j.core;
> > exports org.apache.logging.log4j.core.appender;
> > exports org.apache.logging.log4j.core.appender.db;
> > exports org.apache.logging.log4j.core.appender.nosql;
> > exports org.apache.logging.log4j.core.appender.rewrite;
> > exports org.apache.logging.log4j.core.appender.rolling;
> > exports org.apache.logging.log4j.core.appender.rolling.action;
> > exports org.apache.logging.log4j.core.appender.routing;
> > exports org.apache.logging.log4j.core.async;
> > exports org.apache.logging.log4j.core.config;
> > exports org.apache.logging.log4j.core.config.arbiters;
> > exports org.apache.logging.log4j.core.config.builder.api;
> > exports org.apache.logging.log4j.core.config.builder.impl;
> > exports org.apache.logging.log4j.core.config.composite;
> > exports org.apache.logging.log4j.core.config.json;
> > exports org.apache.logging.log4j.core.config.plugins;
> > exports org.apache.logging.log4j.core.config.plugins.convert;
> > exports org.apache.logging.log4j.core.config.plugins.inject;
> > exports org.apache.logging.log4j.core.config.plugins.util;
> > exports org.apache.logging.log4j.core.config.plugins.visitors;
> > exports org.apache.logging.log4j.core.config.properties;
> > exports org.apache.logging.log4j.core.config.status;
> > exports org.apache.logging.log4j.core.config.xml;
> > exports org.apache.logging.log4j.core.config.yaml;
> > exports org.apache.logging.log4j.core.filter;
> > exports org.apache.logging.log4j.core.impl;
> > exports org.apache.logging.log4j.core.jmx;
> > exports org.apache.logging.log4j.core.layout;
> > exports org.apache.logging.log4j.core.lookup;
> > exports org.apache.logging.log4j.core.message;
> > exports org.apache.logging.log4j.core.net;
> > exports org.apache.logging.log4j.core.net.ssl;
> > exports org.apache.logging.log4j.core.osgi;
> > exports org.apache.logging.log4j.core.parser;
> > exports org.apache.logging.log4j.core.pattern;
> > exports org.apache.logging.log4j.core.script;
> > exports org.apache.logging.log4j.core.selector;
> > exports org.apache.logging.log4j.core.time;
> > exports org.apache.logging.log4j.core.tools;
> > exports org.apache.logging.log4j.core.tools.picocli;
> > exports org.apache.logging.log4j.core.util;
> > exports org.apache.logging.log4j.core.util.datetime;
> >
> > requires transitive java.desktop;
> > requires transitive java.management;
> > requires java.naming;
> > requires transitive java.sql;
> > requires java.rmi;
> > requires transitive java.scripting;
> > requires java.xml;
> > requires org.apache.logging.log4j;
> > requires org.apache.logging.log4j.plugins;
> > //requires transitive com.lmax.distruptor;
> > requires transitive org.osgi.core;
> > requires transitive com.conversantmedia.disruptor;
> > requires transitive com.fasterxml.jackson.core;
> > requires transitive com.fasterxml.jackson.databind;
> > requires transitive com.fasterxml.jackson.dataformat.xml;
> > requires transitive com.fasterxml.jackson.dataformat.yaml;
> > requires transitive org.apache.commons.compress;
> > requires transitive org.fusesource.jansi;
> > uses org.apache.logging.log4j.core.util.ContextDataProvider;
> > provides
> > org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
> > org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
> > provides org.apache.logging.log4j.core.util.ContextDataProvider with
> > org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
> > provides org.apache.logging.log4j.spi.Provider with
> > org.apache.logging.log4j.core.impl.Log4jProvider;
> > provides org.apache.logging.log4j.plugins.processor.PluginService
> with
> > org.apache.logging.log4j.core.plugins.Log4jPlugins;
> >
> >
>
Re: Log4j core
Posted by Matt Sicker <bo...@gmail.com>.
The SQL code is all related to JDBC and related appenders which could go in
their own module. The naming is primarily used for EE stuff which could all
be split out (plus, I don’t think it’s in the default Android variant of
Java). The RMI thing can probably be replaced as you suggested.
JMX/management might have some overlap there? As for the beans package,
that can also be replaced with code instead of linking in that module.
The interesting ones look to be XML and scripting as those are fairly
useful core features, but they could be in their own modules. That would
likely leave core such that it only supports programmatic configuration and
properties files since every other format requires additional modules
besides base.
As for exports, that would likely depend on what’s left in core after
splitting out the above mentioned things.
On Tue, Apr 13, 2021 at 10:43 Ralph Goers <ra...@dslextreme.com>
wrote:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> since have fully modularized it. They simply haven’t performed a release.
>
> As I was going through the module descriptor (see below) it seems to me
> that we have far more dependencies in core than I would really like. For
> example, despite moving the Jackson Layouts to their own modules we still
> have a dependency on Jackson. We also have dependencies on things like
> java.rmi, java.naming, java.sql. I am also not clear on whether they are
> all really optional or not. Ideally, the only required dependency we should
> have is for java.base. For example, we need java.rmi because Log4jLogEvent
> uses MarshalledObject. I have no idea why we need that particular class to
> wrap a log event. Couldn’t we have created our own class for that? We need
> java.desktop because java.beans now lives there. Perhaps we could look at
> what those are and if it is really just one or two utility methods
> implement them locally.
>
> In the meantime I have created an issue with the Disruptor asking for a
> release. I can’t do much more with core until that is available. I can move
> on to other modules.
>
> We also need to look at the list of exports below and the classes in them
> and determine what is really public and what should be private.
>
>
> Thoughts?
>
> Ralph
>
>
> module org.apache.logging.log4j.core {
> exports org.apache.logging.log4j.core;
> exports org.apache.logging.log4j.core.appender;
> exports org.apache.logging.log4j.core.appender.db;
> exports org.apache.logging.log4j.core.appender.nosql;
> exports org.apache.logging.log4j.core.appender.rewrite;
> exports org.apache.logging.log4j.core.appender.rolling;
> exports org.apache.logging.log4j.core.appender.rolling.action;
> exports org.apache.logging.log4j.core.appender.routing;
> exports org.apache.logging.log4j.core.async;
> exports org.apache.logging.log4j.core.config;
> exports org.apache.logging.log4j.core.config.arbiters;
> exports org.apache.logging.log4j.core.config.builder.api;
> exports org.apache.logging.log4j.core.config.builder.impl;
> exports org.apache.logging.log4j.core.config.composite;
> exports org.apache.logging.log4j.core.config.json;
> exports org.apache.logging.log4j.core.config.plugins;
> exports org.apache.logging.log4j.core.config.plugins.convert;
> exports org.apache.logging.log4j.core.config.plugins.inject;
> exports org.apache.logging.log4j.core.config.plugins.util;
> exports org.apache.logging.log4j.core.config.plugins.visitors;
> exports org.apache.logging.log4j.core.config.properties;
> exports org.apache.logging.log4j.core.config.status;
> exports org.apache.logging.log4j.core.config.xml;
> exports org.apache.logging.log4j.core.config.yaml;
> exports org.apache.logging.log4j.core.filter;
> exports org.apache.logging.log4j.core.impl;
> exports org.apache.logging.log4j.core.jmx;
> exports org.apache.logging.log4j.core.layout;
> exports org.apache.logging.log4j.core.lookup;
> exports org.apache.logging.log4j.core.message;
> exports org.apache.logging.log4j.core.net;
> exports org.apache.logging.log4j.core.net.ssl;
> exports org.apache.logging.log4j.core.osgi;
> exports org.apache.logging.log4j.core.parser;
> exports org.apache.logging.log4j.core.pattern;
> exports org.apache.logging.log4j.core.script;
> exports org.apache.logging.log4j.core.selector;
> exports org.apache.logging.log4j.core.time;
> exports org.apache.logging.log4j.core.tools;
> exports org.apache.logging.log4j.core.tools.picocli;
> exports org.apache.logging.log4j.core.util;
> exports org.apache.logging.log4j.core.util.datetime;
>
> requires transitive java.desktop;
> requires transitive java.management;
> requires java.naming;
> requires transitive java.sql;
> requires java.rmi;
> requires transitive java.scripting;
> requires java.xml;
> requires org.apache.logging.log4j;
> requires org.apache.logging.log4j.plugins;
> //requires transitive com.lmax.distruptor;
> requires transitive org.osgi.core;
> requires transitive com.conversantmedia.disruptor;
> requires transitive com.fasterxml.jackson.core;
> requires transitive com.fasterxml.jackson.databind;
> requires transitive com.fasterxml.jackson.dataformat.xml;
> requires transitive com.fasterxml.jackson.dataformat.yaml;
> requires transitive org.apache.commons.compress;
> requires transitive org.fusesource.jansi;
> uses org.apache.logging.log4j.core.util.ContextDataProvider;
> provides
> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
> provides org.apache.logging.log4j.core.util.ContextDataProvider with
> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
> provides org.apache.logging.log4j.spi.Provider with
> org.apache.logging.log4j.core.impl.Log4jProvider;
> provides org.apache.logging.log4j.plugins.processor.PluginService with
> org.apache.logging.log4j.core.plugins.Log4jPlugins;
>
>
Re: Log4j core
Posted by Remko Popma <re...@gmail.com>.
On Wed, Apr 14, 2021 at 12:43 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> since have fully modularized it. They simply haven’t performed a release.
>
> As I was going through the module descriptor (see below) it seems to me
> that we have far more dependencies in core than I would really like. For
> example, despite moving the Jackson Layouts to their own modules we still
> have a dependency on Jackson. We also have dependencies on things like
> java.rmi, java.naming, java.sql. I am also not clear on whether they are
> all really optional or not. Ideally, the only required dependency we should
> have is for java.base. For example, we need java.rmi because Log4jLogEvent
> uses MarshalledObject. I have no idea why we need that particular class to
> wrap a log event. Couldn’t we have created our own class for that?
My memory is a bit vague, but I think the reason for using a JDK class and
not a log4j class was to prevent memory leaks in thread pools shared across
web applications in servlet containers.
Perhaps I am confusing things here, but you may remember that if there is a
reference to a log4j class in a threadlocal, then that can prevent all
log4j classes from being garbage collected when the web app is restarted.
By serializing all data into a JDK class we avoid that problem. We could
also serialize into a byte array I guess, that would work just fine as
well. At the time I thought that MarshalledObject expressed the intent
better than a byte array, and it has some convenience methods for
serializing and deserializing. Other than that there is nothing special
about MarshalledObject itself.
> We need java.desktop because java.beans now lives there. Perhaps we could
> look at what those are and if it is really just one or two utility methods
> implement them locally.
>
> In the meantime I have created an issue with the Disruptor asking for a
> release. I can’t do much more with core until that is available. I can move
> on to other modules.
>
> We also need to look at the list of exports below and the classes in them
> and determine what is really public and what should be private.
>
>
> Thoughts?
>
> Ralph
>
>
> module org.apache.logging.log4j.core {
> exports org.apache.logging.log4j.core;
> exports org.apache.logging.log4j.core.appender;
> exports org.apache.logging.log4j.core.appender.db;
> exports org.apache.logging.log4j.core.appender.nosql;
> exports org.apache.logging.log4j.core.appender.rewrite;
> exports org.apache.logging.log4j.core.appender.rolling;
> exports org.apache.logging.log4j.core.appender.rolling.action;
> exports org.apache.logging.log4j.core.appender.routing;
> exports org.apache.logging.log4j.core.async;
> exports org.apache.logging.log4j.core.config;
> exports org.apache.logging.log4j.core.config.arbiters;
> exports org.apache.logging.log4j.core.config.builder.api;
> exports org.apache.logging.log4j.core.config.builder.impl;
> exports org.apache.logging.log4j.core.config.composite;
> exports org.apache.logging.log4j.core.config.json;
> exports org.apache.logging.log4j.core.config.plugins;
> exports org.apache.logging.log4j.core.config.plugins.convert;
> exports org.apache.logging.log4j.core.config.plugins.inject;
> exports org.apache.logging.log4j.core.config.plugins.util;
> exports org.apache.logging.log4j.core.config.plugins.visitors;
> exports org.apache.logging.log4j.core.config.properties;
> exports org.apache.logging.log4j.core.config.status;
> exports org.apache.logging.log4j.core.config.xml;
> exports org.apache.logging.log4j.core.config.yaml;
> exports org.apache.logging.log4j.core.filter;
> exports org.apache.logging.log4j.core.impl;
> exports org.apache.logging.log4j.core.jmx;
> exports org.apache.logging.log4j.core.layout;
> exports org.apache.logging.log4j.core.lookup;
> exports org.apache.logging.log4j.core.message;
> exports org.apache.logging.log4j.core.net;
> exports org.apache.logging.log4j.core.net.ssl;
> exports org.apache.logging.log4j.core.osgi;
> exports org.apache.logging.log4j.core.parser;
> exports org.apache.logging.log4j.core.pattern;
> exports org.apache.logging.log4j.core.script;
> exports org.apache.logging.log4j.core.selector;
> exports org.apache.logging.log4j.core.time;
> exports org.apache.logging.log4j.core.tools;
> exports org.apache.logging.log4j.core.tools.picocli;
> exports org.apache.logging.log4j.core.util;
> exports org.apache.logging.log4j.core.util.datetime;
>
> requires transitive java.desktop;
> requires transitive java.management;
> requires java.naming;
> requires transitive java.sql;
> requires java.rmi;
> requires transitive java.scripting;
> requires java.xml;
> requires org.apache.logging.log4j;
> requires org.apache.logging.log4j.plugins;
> //requires transitive com.lmax.distruptor;
> requires transitive org.osgi.core;
> requires transitive com.conversantmedia.disruptor;
> requires transitive com.fasterxml.jackson.core;
> requires transitive com.fasterxml.jackson.databind;
> requires transitive com.fasterxml.jackson.dataformat.xml;
> requires transitive com.fasterxml.jackson.dataformat.yaml;
> requires transitive org.apache.commons.compress;
> requires transitive org.fusesource.jansi;
> uses org.apache.logging.log4j.core.util.ContextDataProvider;
> provides
> org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory with
> org.apache.logging.log4j.core.message.ExtendedThreadInfoFactory;
> provides org.apache.logging.log4j.core.util.ContextDataProvider with
> org.apache.logging.log4j.core.impl.ThreadContextDataProvider;
> provides org.apache.logging.log4j.spi.Provider with
> org.apache.logging.log4j.core.impl.Log4jProvider;
> provides org.apache.logging.log4j.plugins.processor.PluginService with
> org.apache.logging.log4j.core.plugins.Log4jPlugins;
>
>