Critical Description
As I described somewhere in the mailing list, there are a handful of SPI-like classes in log4j-core. Some are in o.a.l.l.core, others are in the package where its implementations tend to live. I'm proposing that we refactor some of these interfaces to be placed into the newly created org.apache.logging.log4j.core.spi package namespace. This package could theoretically be split into its own module, but there isn't a real need for that I think. It might help in the OSGi case where we can make a lot more of log4j-core private while only needing to export a few packages. There are some other OSGi benefits I could derive from this, but this is also just a good design idea IMO.
The following classes are proposed to be immediately placed in spi:
- Appender
- ContextSelector
- Filter
- Layout
- NamedContextSelector
- StrLookup
In general, any interface that a plugin implements should probably be placed in here. Some of these interfaces were already in the core package, while others were in subpackages from core. There are other candidates for inclusion that may or may not make sense to include as well:
- Configuration
- ConfigurationMonitor
- LoggerConfig (might warrant its own interface)
- ConfigurationListener/Reconfigurable
- Filterable
- LogEventFactory and LogEventInput (might want to rename one of these)
- Advertiser
- PatternConverter, ArrayPatternConverter, AnsiConverter
- ErrorHandler
- LifeCycle
- LogEvent
Which classes might be useful to include in spi? In general, if an interface consumes or produces another interface, then all those interfaces should probably be in the spi (or api) transitively.