commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [joran] example (was Re: [Latka][Proposal] Make Jelly a required dependency?)
Date Mon, 14 Oct 2002 20:07:03 GMT

Here is a sample log4j config file in XML:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration debug="true"
                      xmlns:log4j='http://jakarta.apache.org/log4j/'>

   <appender name="CON" class="org.apache.log4j.ConsoleAppender">
     <param name="Threshold" value="INFO"/>
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%5p [%t] %c - %m%n"/>
     </layout>
   </appender>

   <appender name="FOO" class="org.apache.log4j.FileAppender">
     <param name="File" value="foo.log"/>
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%r %p %t %c - %m%n"/>
     </layout>
   </appender>

   <appender name="UNUSED" class="org.apache.log4j.net.SMTPAppender">
     <param name="To" value="ceki@apache.org"/>
     <param name="Host" value="xyz.com"/>
     <layout class="org.apache.log4j.HTMLLayout"/>
   </appender>

   <logger name="com.foo">
     <level value ="info" />
     <appender-ref ref="FOO" />
   </logger>

   <root>
     <level value ="debug" />
     <appender-ref ref="CON" />
   </root>
</log4j:configuration>


The noteworthy point is that the appender element is used only if root
or a logger element references it. For example, the UNUSED appender,
which is not referenced by any root or logger element, will not be
created nor configured. I call this the 0th Property.

Property 0: It's the root or loggers elements which "drive"
the appender elements.

Another interesting point is that different appender elements may have
different nested elements which must be evaluated differently. For
example,

   <appender name="EMAIL" class="org.apache.log4j.net.SMTPAppender">
     <param name="To" value="ceki@apache.org"/>
     <param name="Host" value="xyz.com"/>
     <layout class="org.apache.log4j.HTMLLayout"/>
     <trigger class="org.apache.log4j.someClass">   <--- trigger is a 
special tag
         <param name="maxCount" value="1000"/>
     </trigger>
   </appender>

<trigger> is an SMTPAppender specific tag.

Another example,

   <appender name="ROLLING" class="org.apache.log4j.RollingAppender">
     <param name="File" value="comfoo.log"/>
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%r %p %t %c - %m%n"/>
     </layout>
     <rolloverStrategy class="org.apache.log4j.SizeStrategy">  <-- special tag
       <param name="maxSize" value="100KB"/>
     </rolloverStrategy>
     <namingStrategy class="org.apache.log4j.SuffixStrategy">  <-- special tag
       <param name="type" value="numerical"/>
       <param max="max" value="-1"/>
     </rolloverStrategy>
   </appender>

in the above example <rolloverStrategy> and <namingStrategy> are
RollingAppender specific tags.

Log4j could support such tags using the addXXX paradigm that Ant uses
for its tasks.

The remaining desired properties are

1) low redundancy in the processing code

2) ability to parse totally unknown tags that are *not*
nested within primary level tasks, e.g. <root>, <logger>, <appender>
tags.

I think that a rule based system such as Digester can take care of
properties 1 and 2 but not property 0 defined above. Can jelly?

BTW, am I making any sense?

At 17:00 14.10.2002 +0100, James Strachan wrote:
>From: "Ceki Gülcü" <ceki@qos.ch>
> >> Have you any examples of what joran
> >>might look like yet?
> >
> > No, I do not have examples, except in my head.
>
>Any chance you could type a snippet of an example thats in your head down in
>an email; I'm interested to hear what you were thinking of.
>
> > Moreover, one wonders at the
> > sanity of the Joran enterprise when a library like Jelly is already
> > available.
>
>Jelly can be molded into many shapes via libraries so maybe Jelly could
>implement Joran; however thats purely an implementation detail. Lets ponder
>a little on what Joran could look like to an end user first before worrying
>about such details.
>
>James
>-------
>http://radio.weblogs.com/0112098

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message