Logback Refactoring Ideas
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@wagenknecht.org http://wagenknecht.org/
Maybe I just haven't encountered them but I've never seen a case where projects would have benefited from this type of fine grained packaging. So at the very least I would think that the first four packages you identify should be one package. As far as the versioning goes, I would recommend against independent versions unless you are going to establish a consistent and rigid versioning policy dealing with API changes and backwards/forwards compatibility. To date logback has not had that and if it doesn't in the future you'll end up having to describe exactly which versions of which packages work with exactly which versions of other packages. That would be very cumbersome and messy I think. On 9/1/10 3: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
-- Chad La Joie http://itumi.biz trusted identities, delivered
Am 01.09.2010 12:50, schrieb Chad La Joie:
Maybe I just haven't encountered them but I've never seen a case where projects would have benefited from this type of fine grained packaging.
I put the ideas together because we would benefit from them. Our project just need the logging essentials but not the XML/Groovy configuration stuff or any of the other appenders. However, there were releases in the past that just contained modifications in those area and we were confronted with requests to updated an "outdated" version for Logback which actually wasn't outdated. I can also see some benefits on embedded devices which look for ever kB they could save.
As far as the versioning goes, I would recommend against independent versions unless you are going to establish a consistent and rigid versioning policy dealing with API changes and backwards/forwards compatibility. To date logback has not had that and if it doesn't in the future you'll end up having to describe exactly which versions of which packages work with exactly which versions of other packages. That would be very cumbersome and messy I think.
I don't really see this as an issue. There are well established best practices for versioning as well as defining requirements, etc. Maybe I'm wrong but to me it seems that Ceki already started adopting them for SLF4J and also for Logback (that's why it's still pre-1.0 to allow evolution of the API). Another benefit is that Logback Essentials could be declared 1.0 independent from other packages. IMHO this would also be a positive signal to the community. And, as I said before, although the packages may have individual versions they could still be released as one convenience drop. -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/
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@wagenknecht.org http://wagenknecht.org/
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
participants (3)
-
Chad La Joie -
Gunnar Wagenknecht -
Ralph Goers