Yoav,
Yes, these are both ideas that I've been looking at. If I change Logger (either wrap or create a new one), then I will probably use a separate repository to avoid the problems that Ceki discusses in his book.
As for Filters, the problem there is that Filters are attached to Appenders, not to Loggers. In my first post two weeks ago, Paul responded with the same suggestion, but since the permitted types will vary by each logger, I would have to either build a parallel hierarchy to hold the types for each logger, or define appenders for each logger that I wanted to change the permitted types (and that could get rather ugly). I understand how to use MDC to tag the LogEvent with the type, but then I need to see if that logger should allow that type, that needs to be stored either with the logger, or in yet another "global" collection keyed by logger.
And again, I'm not trying to say that levels are bad, it just that they are only one way of determining what should get logged. Thanks for the suggestions!
Yes, I totally agree. The current design of log4j caters for categorizing messages by locality, that is the place where the logging request is issued (package, class). Although most of the time categorizing logs by locality serves us well, very well, we sometimes need to categorize the logging request by some other criteria.
I think your observation is quite insightful.
--- regards --- Larry
-- Ceki For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
