Looking at the log4j code, it seems the filters are ordered using their ids, so in your case "accept" and "deny". So I think the order should be ok. Can you try changing their name so that the order would be reversed ?
On Mon, Jan 30, 2012 at 11:09, Bengt Rodehav <be...@rodehav.com> wrote: > OK - I didn't know that. > > Do you think I should post a message on ops4j's mailing list about this? > > The reason I tried the Karaf mailing list first is that I believe this > whould be a pretty common (and useful) configuration. In my case, I will > probably create logs per camel context and not per bundle but I still need > the possiblity to configure more detailed logging for a specific MDC value. > > Have you tried something similar yourself? > > I actually posted a question on Stackoverflow about this as well: > > http://stackoverflow.com/questions/9049119/set-log-level-based-on-mdc-value-in-log4j > > No replies unfortunately. The filtering approach would be an alternative > (although not as elegant way) to accomplish what I wanted. > > /Bengt > > 2012/1/30 Guillaume Nodet <gno...@gmail.com> >> >> No, the support has been added in log4j: >> http://svn.apache.org/viewvc?view=revision&revision=821430 >> >> On Mon, Jan 30, 2012 at 10:30, Bengt Rodehav <be...@rodehav.com> wrote: >> > Hello Guillaume, >> > >> > Doesn't the filter support in log4j require XML configuration (not >> > properties file)? If so, then I assume that Pax-logging has added the >> > possibility to use filters using a properties file configuration. >> > >> > /Bengt >> > >> > >> > 2012/1/30 Guillaume Nodet <gno...@gmail.com> >> >> >> >> 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 >> > >> > >> >> >> >> -- >> ------------------------ >> 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
