logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Proposal to move some interfaces in log4j-core.
Date Thu, 01 May 2014 06:25:17 GMT
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


On Apr 28, 2014, at 4:24 PM, Matt Sicker <boards@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 <boards@gmail.com>

View raw message