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
