1) I need to find some time to look at the JMX stuff. The last time I looked at it I noticed that some of it was implemented incorrectly - but i don’t recall exactly what. I like this being in a separate jar as including it would automatically mean the user wants JMX support. I like that. So I would prefer it be in its own subproject. 2) I’ve never been comfortable with the automatic startup in a web container just because the Log4j core jar is present. For that reason alone I prefer it to be in its own jar. Being able to disable the shutdown hook just because some class in the jar is present is another great reason. I know it used to be a separate jar and we moved it into core (for reasons I don’t remember at the moment), but I think that was a mistake and I would like to see this in its own subproject.
In general, grouping all of the interfaces and/or classes that we consider to be “public” in some manner or other within core is a good idea. OTOH, we could move all the internal classes under an internal package, so anything not there is public. I suspect the public classes might include more than you have listed though. But it is probably better to start off being conservative. Ralph On Apr 28, 2014, at 4:24 PM, Matt Sicker <[email protected]> wrote: > 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 <[email protected]>
