Actually, the filters support is built into log4j, but if there's really a problem we can always fix it in pax-logging until the patch is released in log4j.
On Mon, Jan 30, 2012 at 10:21, Guillaume Nodet <gno...@gmail.com> wrote: > The filter support has been added in pax-logging. > Have a look at > > https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/PaxLoggingConfigurator.java > > You may very well be right that the order isn't kept, which would > definitely be a bug. > > On Mon, Jan 30, 2012 at 10:17, Bengt Rodehav <be...@rodehav.com> wrote: >> I have the following configuration in my org.ops4j.pax.logging.cfg: >> >> # Per bundle log at INFO level >> log4j.appender.bundle=org.apache.log4j.sift.MDCSiftingAppender >> log4j.appender.bundle.key=bundle.name >> log4j.appender.bundle.default=karaf >> log4j.appender.bundle.appender=org.apache.log4j.RollingFileAppender >> log4j.appender.bundle.appender.MaxFileSize=10MB >> log4j.appender.bundle.appender.MaxBackupIndex=2 >> log4j.appender.bundle.appender.layout=org.apache.log4j.PatternLayout >> log4j.appender.bundle.appender.layout.ConversionPattern=%d{ISO8601} | %-5.5p >> | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n >> log4j.appender.bundle.appender.file=${logdir}/bundles/$\\{bundle.name\\}.log >> log4j.appender.bundle.appender.append=true >> log4j.appender.bundle.threshold=INFO >> >> # TRACE level for specific bundle - should normally be disabled >> log4j.appender.bundle_trace=org.apache.log4j.sift.MDCSiftingAppender >> log4j.appender.bundle_trace.key=bundle.name >> log4j.appender.bundle_trace.default=karaf >> log4j.appender.bundle_trace.appender=org.apache.log4j.RollingFileAppender >> log4j.appender.bundle_trace.appender.MaxFileSize=20MB >> log4j.appender.bundle_trace.appender.MaxBackupIndex=1 >> log4j.appender.bundle_trace.appender.layout=org.apache.log4j.PatternLayout >> log4j.appender.bundle_trace.appender.layout.ConversionPattern=%d{ISO8601} | >> %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n >> log4j.appender.bundle_trace.appender.file=${logdir}/bundles/trace/$\\{bundle.name\\}.log >> log4j.appender.bundle_trace.appender.append=true >> log4j.appender.bundle_trace.threshold=TRACE >> log4j.appender.bundle_trace.filter.accept=org.apache.log4j.varia.StringMatchFilter >> log4j.appender.bundle_trace.filter.accept.StringToMatch=bunde.name:org.apache.camel.camel-core >> log4j.appender.bundle_trace.filter.accept.AcceptOnMatch=false >> log4j.appender.bundle_trace.filter.deny=org.apache.log4j.varia.DenyAllFilter >> >> The intention is to have bundle specific logs at INFO level but have a >> separate TRACE log for a specific bundle. The latter is not enabled by >> default but only when debugging. >> >> The problem is that the DenyAllFilter seems to take precedence over the >> StringMatchFilter. I believe that when listed in the order I do, the bundle >> with the name "org.apache.camel.camel-core" should be logged at TRACE level >> but no other bundles. Could it be that the ordering of filters are not >> preserved? I think that native log4j only supports filters when using XML >> configuration and I assume that the Karaf filtering support has been added >> on top of log4j (or is it in Pax-logging)? Has the ordering of filters been >> taken into account? >> >> I've been testing this on Karaf 2.2.0 with Pax logging 1.6.0. >> >> /Bengt > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
