Yeah, I was looking at minimal changes. I like the idea of making it more obvious which are internal classes and which are public APIs.
The web module sounds like a good idea, too. I still don't understand exactly why it's needed for using log4j in a web container on its own (besides the shutdown hook? that does seem to be the entire point of the web module). On the other hand, adding support for lifecycle support on web containers can be considered similar to adding OSGi lifecycle support. They're purely hooks into certain containers that have lifecycle management outside of the JVM lifecycle. On 1 May 2014 01:25, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 <boa...@gmail.com> 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 <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
