Hi Chetan, yes, we should make the additivity configurable, defaulting to true for compatiblity sounds good.
Thanks Carsten 2013/9/22 Chetan Mehrotra <[email protected]> > Hi Carsten, > > Initially I did not set additivity for OSGi configured loggers to > true. That caused issue in some situations where a Sling based app > like CQ defines multiple fine grained config which logs output from > various loggers (request log, query log etc) to separate files. With > new Logback stuff all the logs were also getting recorded in error.log > (defined at root level) hence polluting it > > One thing we can do is add support for configuring additivity in OSGi > config also which by default is true. And then have an upgrade plugin > which can set the default value to false for config in an upgraded > system. > > regards > Chetan > Chetan Mehrotra > > > On Fri, Sep 20, 2013 at 12:05 PM, Carsten Ziegeler <[email protected]> > wrote: > > Hi, > > > > while trying out the new logback based logging implementation I stumbled > > across the handling of the current configurations (pre logack impl): if > > these are used, then if I understand it correctly, a logger is configured > > with an appender and logger.setAdditive(false) is called which prevents > > going up the category hierarchy and calling other appenders. > > This is for compatibility, but imho defeats using a main feature of > > logback: being able to call mulitple appenders. > > Is my assumption so far correct? > > > > So right now, it seems to me, that we either break compatiblity here > (which > > really shouldn't hurt) or require every user to migrate the > configuration, > > which seems pointless to me. > > > > WDYT? > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > [email protected] > -- Carsten Ziegeler [email protected]
