[jira] [Closed] (LOG4J2-606) Consider moving log4j-core SPI-like classes to its own package.

["Matt Sicker (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker closed LOG4J2-606.
------------------------------
    Resolution: Won't Fix

Way too late to be moving classes like these around. No big deal, anyway.

> 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.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org