Hi I have now committed Chetans latest patch over the commons.log bundle. That is commons.log is now logback based and the old implementation has gone (will still be available in release 3.0.2 under vote and the SVN history).
Please check it out, and please crosscheck whether the license files look ok (we embedd the logback core and classic bundles as well as a client side JavaScript library for the web console). Regards Felix Am 22.08.2013 um 03:13 schrieb Chetan Mehrotra: > Hi, > > I am done with most of the planned features with Sling Logabck extension > [1]. To summarize it supports following features > > * Compatible with existing Sling Commons Log > * LogBack configuration can be provided via Logback config xml > * ConfigurationAdmin integration - Logback Config can be enhanced via > config obtained from OSGi configuration admin > * Supports Appenders via Whiteboard pattern > * Support providing Logback config as fragments through OSGi Service > Registry > * Feature rich WebConsole Plugin and Configuration Printer support > > I have provided the implementation zip as part of SLING-2024. Current test > coverage stands at ~50%. > > Some queries going forward > > 1. What should be the artifactId of the new implementation > Currently I have set the artifactid (and package names) as > org.apache.sling.extensions.logback. Should it be set to > org.apache.sling.commons.log with major version number upgrade. As that > would allow easier upgrades? > > Kindly have a look at the patch provided and provide your feedback. > > regards > Chetan > > [1] https://github.com/chetanmeh/sling-logback > [2] https://issues.apache.org/jira/browse/SLING-2024 > [3] http://logback.qos.ch/manual/configuration.html#fileInclusion > Chetan Mehrotra > > On Tue, Aug 13, 2013 at 6:03 PM, Bertrand Delacretaz <[email protected]> > wrote: >> On Tue, Aug 13, 2013 at 1:48 PM, Chetan Mehrotra >> <[email protected]> wrote: >>> ...I just swapped the log >>> implementation in existing system and saw if the log were generated as >>> expected or not. Adding automated testcase for such scenarios would >>> take some decent effort... >> >> granted...but I think we need this as subtle differences in the log >> configuration mechanisms can lead to hard to troubleshoot issues in >> the field. >> >>> >>> So before I invest time in that wanted to see if there is interest in >>> the Logback based implementation... >> >> I haven't looked at your patch so far but in general I think it's a >> great idea, especially as it brings MDC and Markers with it. >> >> -Bertrand
smime.p7s
Description: S/MIME cryptographic signature
