[logback-dev] Logback Refactoring Ideas

[Ralph Goers]

Ceki created core so that he could build logback-classic, logback-access and logback-audit on top of them. I'm not a particular fan of this myself.  If you look at access and classic you will notice that both have a PatternLayout, DBAppender, SMTPAppender, SocketAppender, etc. Also, the Context used in classic isn't the same as the context used in access.

I'm not sure that at this point Logback can be refactored as you would like.

I would like to point out that Log4j is in the early phase of 2.0 and could really use people to work on suggestions like this.  

Ralph

On Sep 1, 2010, at 12:01 AM, Gunnar Wagenknecht wrote:

> Greetings Logback developers,
> 
> I'm regularly packaging Logback OSGi bundles for Eclipse Orbit. The
> other day I was wondering if the current core vs. classic split of
> Logback is really useful for people, i.e. is anybody out there using
> _just_ Logback core without any of the classic pieces?
> 
> For example, PatternLayout is classic but the file appenders are in
> core. Isn't PatternLayout an essential logging element? Also, when an
> issue in the XML/Groofvy configuration implementation is detected, a
> full new release of core+classic is required. Wouldn't it be better if
> the parts could evolve independent?
> 
> Thus, I was thinking of a more fine grained split based on functional
> units. For example like this:
> 
> -> Logback Logging Essentials
> All the essential logging related stuff form core+classic (logger,
> levels, (turbo) filters, console appender, encoders, layouts, basic
> configurator)
> 
> -> Logback SLF4J Logger
> The native SLF4J logger.
> 
> -> Logback XML/Groovy Configuration Pack
> The advanced configuration functionality based on Joran for XML + Groovy.
> 
> -> Logback File Logging Extension Pack
> File appenders
> 
> -> Logback Web Extension Pack
> Servlet integration, HTML appenders, etc.
> 
> -> Logback Enterprise Extension Pack
> Advanced appenders (JMS, Database), JNDI stuff, etc.
> 
> 
> There could be other extension packs as well. The challenge IMHO is to
> collect all the essential things together for having a really small
> Logback package that contains only the minimum required for logging (to
> console and to files). Maybe the file logging package can be part of the
> essential package.
> 
> Anyway, another important point is that the packages are released
> independently, i.e. get their own version. Thus, when an issue in the
> XML/Groovy configuration package is detected, no new release of the
> essential pack is necessary.
> 
> There can still be joint releases of all packs together (for example, to
> have a better brand recognition) - the "Logback 1.2" release. But in
> this case, Logback 1.2 means essentials 1.0.4, slf4j-logger 1.0.1,
> configs 1.2.0, file logging 1.1.24, etc.
> 
> Thoughts?
> 
> -Gunnar
> 
> -- 
> Gunnar Wagenknecht
> gunnar at wagenknecht.org
> http://wagenknecht.org/
> 
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev