Hi Ceki, Thanks again for the thoughtful reply. Ceki Gulcu wrote:
Ignoring performance considerations, i.e root of all long discussions, if you wish to filter per user or per group, does it also make sense to add per logger filtering on top of filters based on the user? Does your use case call for "user+logger"-based filters or just user-based filters?
I'm not sure I follow the "per logger filtering on top of" part. Are you describing a logger-based appender filter that would follow an appender filter for user (or other context)?
If your use case calls for user-based filters, then is it accurate to say that your request for "user+logger"-filters is essentially motivated by improving filtering performance?
You are correct - the primary reason for the request is performance. The secondary and tertiary reasons are simplification of configuration and filter implementation. In typical use our sever will be handling high request volume. This is what really attracted us to the TurboFilter concept. With it we can avoid message building for all appenders by controlling the verbosity primarily at the logger level. We tend to view all appenders as equivalent, differing primarily by where/how the log data is stored. We may occasionally want to select different messages for different targets, but that is far down on our list of use cases. In our system we are likely to have dozens of per-class loggers, fewer per-package loggers and a handful of other "shared" loggers. What we are wanting to accomplish with filters is to govern certain loggers based on application-level context (such as "user", but other objects as well). The logger in question may be a parent or perhaps package-level logger that we want to tune to control logging for all components of the package. Of course, we have several sub-systems that may have different criteria governing their logging. This would most naturally be realized using multiple filter instances. Since these are global, they must filter not only based on the application-relevant context, but also on the logger. We were concerned that having multiple such filters could easily become a performance problem. Especially since (in our case) most filters do not apply to most logger instances. The additional coding to include the logger selection criteria and the resulting configuration data to manage it were of some concern, but we didn't rank them very high (no system is a perfect fit for everyone's environment). Best regards, Don