log4j StringMatchFilter porting to logback
Hi there, it's me again, just wondering, what's the best way to reproduce the behaviour of log4j StringMatchFilter in logback? Do I have to use ch.qos.logback.core.filter.EvaluatorFilter ? Regards, -- Fabio Erculiani
On 22/02/2011 5:47 PM, Fabio Erculiani wrote:
Hi there, it's me again, just wondering, what's the best way to reproduce the behaviour of log4j StringMatchFilter in logback? Do I have to use ch.qos.logback.core.filter.EvaluatorFilter ?
You can re-write StringMatchFilter by extending Filter or AbstractMatcherFilter classes both located in the ch.qos.logback.core.filter package. You could also learn to use EvaluatorFilter with GEventEvaluator (takes an expression in Groovy) or JaninoEventEvaluator (takes an expression in Java. See [1] for details. Re-writing StringMatchFilter should be rather easy and will not require any other dependencies. Using JaninoEventEvaluator will require Janino and GEventEvaluator will require the Groovy runtime. However, JaninoEventEvaluator/GEventEvaluator are much easier to extend should your needs go beyond just string matching on the log message. HTH, -- Ceki [1] http://logback.qos.ch/manual/filters.html#evalutatorFilter
Thanks a lot Ceki, So, my idea was to subclass EvaluatorFilter, write my decide logic (I need to add some hardcoded matching rules there, then call super.decide()), and use a matcher like explained here: http://logback.qos.ch/manual/filters.html#matcher Can you confirm that this strategy doesn't require any fancy dep? (I would really like to avoid pulling in groovy or janino stuff). Thanks, Hope you find my questions useful for the FAQ ;-) -- Fabio Erculiani
Hi Fabio, EvaluatorFilter requires an evaluator instance. However, since you do not want to use the JaninoEvaluator nor GEvaluator, you should extend AbstractMatcherFilter instead. Extending EvaluatorFilter would be unnecessarily convoluted. HTH, -- Ceki On 24.02.2011 11:30, Fabio Erculiani wrote:
Thanks a lot Ceki, So, my idea was to subclass EvaluatorFilter, write my decide logic (I need to add some hardcoded matching rules there, then call super.decide()), and use a matcher like explained here: http://logback.qos.ch/manual/filters.html#matcher
Can you confirm that this strategy doesn't require any fancy dep? (I would really like to avoid pulling in groovy or janino stuff).
Thanks, Hope you find my questions useful for the FAQ ;-)
Ok now I got that part. Still, it's very unclear to me how I could match a string declared in logback.xml (even regexp would be fine) using AbstractMatcherFilter, without either pulling in Groovy or Janino. Could you be more clear? It doesn't seem possible to me, and the manual is a bit vague. Thanks, -- Fabio Erculiani
On 24.02.2011 12:22, Fabio Erculiani wrote:
Ok now I got that part. Still, it's very unclear to me how I could match a string declared in logback.xml (even regexp would be fine) using AbstractMatcherFilter, without either pulling in Groovy or Janino. Could you be more clear? It doesn't seem possible to me, and the manual is a bit vague.
Have you seen the log4j's StringMatchFilter? The same approach is applicable in logback.
Thanks,
On 28.02.2011 10:06, Fabio Erculiani wrote:
Ceki, you mean, using JavaBeans?
If your question is about how the Joran (logback's XML configurator) injects properties into components such as your filter, then note that you don't have todo anything to have properties injected into your filter. Just give it a try... -- Ceki
On Mon, Feb 28, 2011 at 9:41 AM, Ceki Gulcu <ceki@qos.ch> wrote:
On 28.02.2011 10:06, Fabio Erculiani wrote:
Ceki, you mean, using JavaBeans?
If your question is about how the Joran (logback's XML configurator) injects properties into components such as your filter, then note that you don't have todo anything to have properties injected into your filter. Just give it a try...
Thanks Ceki, I'll give it a try.
-- Ceki
-- Fabio Erculiani
participants (3)
-
Ceki Gulcu -
Ceki Gülcü
-
Fabio Erculiani