Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-606

Consider moving log4j-core SPI-like classes to its own package.

    XMLWordPrintableJSON

    Details

    • Type: Brainstorming
    • Status: Closed
    • Priority: Critical
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core
    • Labels:

      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:

      1. Appender
      2. ContextSelector
      3. Filter
      4. Layout
      5. NamedContextSelector
      6. 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.

        Attachments

        1. SPI_refactor.patch
          134 kB
          Matt Sicker

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mattsicker Matt Sicker
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: