Hi Chetan, The issue for me is one of consistency. One of the key design principals of Sling is that everything is a resource. Which includes configuration. In our ecosystem, we have multiple different configuration methods:
1) OSGi ConfigAdmin - configured through sling:OsgiConfig nodes and .config files, including writeback to ensure consistency. 2) Resource Structures, e.g. /etc/map and rewriter configuration - these are used in cases where the configuration is too complex for ConfigAdmin 3) XML files as resource - used where the effort of creating support for a resource structure is too high compared with the amount of expected change. The only example I'm aware of in Sling is the Jackrabbit repository.xml. It is a bit more common in CQ, e.g. XSL:FO configuration and XSS Protection. Where this is done, the path to the resource should be configurable (this, sadly, is not always done, but those are IMHO bugs). 4) Framework properties - used for bootstrapping, e.g. runmodes. In some cases, we *combine* these techniques, i.e. configuration from /etc/map is combined with the ConfigAdmin-based configuration of the ResourceResolver. I don't see why logging requires going outside this practice. It didn't before Logback. For the bootstrap problem, we were doing this before with framework properties. Couldn't Logback be configured using the same framework properties as before and then switch over to a resource-based configuration once the resource resolver was available? Regards, Justin On Sat, Nov 16, 2013 at 1:36 AM, Chetan Mehrotra <[email protected]> wrote: > Probably I was not clear in my earlier mail > > I am suggesting that we ship a default logback.xml with Sling which > gets placed under ${sling.home}/etc/logback.xml. The default xml would > look like [1]. It provide following benefits > > 1. For log files which are not that critical we can set immediateFlush > to false thereby increasing performance a bit > 2. Document some useful logger categories which have there log level > set to INFO by default. A user can then set it to debug for debugging > purpose > 3. It also provides an easier way to bootstrap logging config in > automatic deployments. > 4. It simplifies using Logback features which are not possible via > OSGi way. If we do not ship such default config xml users would have > to setup on there own thus making such Logback features difficult to > configure > > The user can still continue to use OSGi based configuration for log > writers and loggers > > In addition I was also suggesting that we do not document the OSGi > config way to configure the appender and instead recommend users to > configure appenders in logback.xml. But looks like people prefer the > OSGi way (see below). In that case I would continue to include doc > about that feature in new doc. > >> . I think it is safe to assume that the >> existing file-based logging would represent the primary use cases for >> logging, even with the enhanced options provided by Logback. So why >> not continue to make the most common use case simple > > ACK. The OSGi way would continue to be supported as mentioned earlier > >> XML file editing >> should only be necessary in edge cases (or not-so-edge cases which we >> just haven't had time to simplify yet). > > FWIW I find the logger names distributed across multiple OSGi configs > difficult to use. For example in current mode you cannot change log > level of just one category in a particular OSGi config. To change log > level you need to remove that logger form given config and create a > new osgi config with different log level. For me its easier if all > such logger levels are configured discretely in a xml file and I can > directly tweak them there. > >> And it's 2013, we are still wrapping another generic logging handling around >> another one? > > Do not know what do you mean by wrapping here. In current > implementation we are not wrapping any other library. Its default > Logback directly being used which natively implements the Slf4j API. > We just provide a better integration with OSGi feature set > > Chetan Mehrotra > [1] https://gist.github.com/chetanmeh/7496571
