Hi Chetan, On Tue, Nov 19, 2013 at 12:12 PM, Chetan Mehrotra <[email protected]> wrote: >>> 1. Configures itself with a pre packaged config file within the Bundle >> >> To which bundle is this referring? The Logback integration bundle? If >> so, when would this file be used? > > It refers to the org.apache.sling.commons.log-4.0.0 bundle which > packages a default logback.xml as part of bundle classpath. This file > is used to bootstrap Logback > >>> 2. Can be configured to configure Logback from a file on file system. >>> This would allow one to customize it on a per Sling instance basis >> >> I think this functionality needs to be removed as it isn't consistent >> with the rest of Sling. > > I disagree. This functionality proves to be quite useful in > configuring Logging and I would not like that Logging system depends > completely on any other system for configuration. At very minimum it > should be possible to configure Logging without depending on any other > support. One use would be in cluster deployment where to troubleshoot > issue on a particular node an admin can start the system with specific > logback.xml. It can use those Logback features which are not possible > to configure via OSGi.
As I said, if you want to configure logging using a file, you can do this with the File System Resource Provider. If you want to support directly loading from a file for bootstrapping purposes, i.e. there's a path in a framework property which is used until the ResourceResolverFactory is available, that's fine with me, but IMHO overkill as we already have the org.apache.sling.commons.log.level property which is there to help troubleshoot issues during bootstrapping. > > This is similar to how so far JR2 configuration was handled via > repository.xml and Repository bundle provided an option to provide a > custom repository.xml for first startup. > >>> 4. Can be further extended via Config Fragments [2]. It supports an >>> extension point to provide >>> xml fragments from different source. Later we can add an impl which >>> can look up config >>> fragments in JCR repo and provide it to Common Log >> >> This needs to be done against the resource resolver, not the JCR >> directly. And if you do that, then #2 isn't necessary as you can use >> the File System Resource Provider to point the configured resource >> path to a file system resource. > > Commons Log bundle exposes an extension point and that can be > implemented using any possible means. In Sling one can implement it > against ResourceProvider also. However it would always be *one* of the > option. My point is that "one" shouldn't need to implement this. It needs to be a standard feature. And it should be documented as the secondary way to configure Logback, with ConfigAdmin being the primary way. > >> In my opinion, these are showstoppers and warrant cancelling the >> release. Otherwise, we are stuck with a backwards compatibility issue. > > I still do not get the concern here. The Log bundle provides various > means to configure Logback and users are free to use any of the means. > Currently the Log bundle can has no dependency on Sling API and can > easily be used in non Sling containers also. All these options are > fully supported and well documented with backing testcase. As I said, my concern is one of consistency. The first goal of Sling log support should be to support Sling-based applications. If it can work outside of Sling, that would be nice to have, but IMHO is a non-goal, especially if it results in an inconsistency. Justin > > regards > Chetan
