[
https://issues.apache.org/jira/browse/LOG4J2-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-606:
-------------------------------
Attachment: SPI_refactor.patch
Proposed patch using the six mentioned classes.
> Consider moving log4j-core SPI-like classes to its own package.
> ---------------------------------------------------------------
>
> Key: LOG4J2-606
> URL: https://issues.apache.org/jira/browse/LOG4J2-606
> Project: Log4j 2
> Issue Type: Brainstorming
> Components: Core
> Reporter: Matt Sicker
> Priority: Critical
> Labels: api, core, spi
> Attachments: SPI_refactor.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
