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:37:40 GMT
Property 0 says that parsing of appender tags are driven by logger
tags. For example, the following config script does nothing.

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

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

   <appender name="CONSOLE" 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>
</log4j:configuration>

In particular, the CONSOLE appender is not created because no logger
references it.

Property 0 requires the XML processor to access elements that have
been already defined. With Digester which is SAX based, there is no
way for a rule to trigger parsing of an element that was already
parsed by the SAX parser. In other words, using SAX you cannot access
elements backwards or forwards. You only have access to the current
element.  Please correct me if I am wrong.

At 13:18 14.10.2002 -0700, you wrote:
>Can you explain the property 0 thing a little more?  I don't understand 
>why Digester cannot handle it.
>
>Thanks,
>Scott
>
> > -----Original Message-----
> > From: Ceki Gülcü [mailto:ceki@qos.ch]
> > Sent: Monday, October 14, 2002 1:07 PM
> > To: Jakarta Commons Developers List; Jakarta Commons Developers List
> > Subject: Re: [joran] example (was Re: [Latka][Proposal] Make
> > Jelly a required dependency?)
> >
> >
> >
> > 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>
> >
> >
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>

--
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