>> 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.

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.

> 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.

regards
Chetan

Reply via email to