Pretty much all the interfaces in log4j-core except for: * jmx * web * maybe some subpackages in appender (e.g., rewrite, rolling)
I'm proposing we put all these public API classes into either o.a.l.l.core or making a new package for it such as o.a.l.l.core.api. This can aid in making it obvious where all the interfaces that should be extended for custom plugins are. It can also be useful in exposing less classes to OSGi (reducing the number of exported packages necessary). Here's a list of the qualifying interfaces I'm talking about: * ManagerFactory * Configuration * ConfigurationListener * ConfigurationMonitory * Reconfigurable * Filterable * StrLookup * Advertiser * LogEventInput * AnsiConverter (would this be useful?) * ArrayPatternConverter * PatternConverter * ContextSelector * NamedContextSelector * LogEventFactory * ResourceLoader (new interface inside helpers.lang) * Clock * SecretKeyProvider Related idea: would grouping together any abstract base implementation classes like AbstractLayout, AbstractAppender, AbstractManager, AbstractConfiguration, AbstractFilter, AbstractFilterable, etc., into some higher level package be useful? Basically make the package structure easier to understand as a plugin developer. The log4j-api package is very nicely structured and is very easy to understand as a developer. We could do something similar with log4j-core. -- Matt Sicker <boa...@gmail.com>
