jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject My first impressions as a Cactus user, [WAS: Log4j integration testing...]
Date Tue, 11 Jan 2005 13:24:35 GMT
At 11:38 AM 1/9/2005, Vincent Massol wrote:
>Hi Ceki,
>
>See
>http://jakarta.apache.org/cactus/integration/manual/howto_config.html#loggin
>g for how we currently configure Cactus logging.

I found the "Servlet Sample Walk through" [1] extremely useful. On the 
other hand, as a beginner, the "How it works" [2] was a bit overwhelming 
and somewhat of a turn off. In my very humble opinion, you should consider 
removing the link to [2] from the main cactus page. (Given the size and 
breadth of Cactus, I am sure that there will be plenty of other occasions 
to confuse the user later on.)

As for configuring Cactus to use log4j, that was easy as well although I 
had to go look in the source code to refresh my memory about how log4j 
treated values passes with the log4j.configuration system property. I don't 
think all users will have the same reflex. :-)

The Cactus docs in [3] could mention that the "log4j.configuration" system 
property admits a URL as a value. The resource references by the URL can be 
a properties file as well as an XML file. Moreover, the URL can be a 
relative, so the all of the following would work correctly assuming the 
log4j configuration file is in $CACTUS_HOME/target/

log4j.configuration=file:./target/log4jClient.xml
log4j.configuration=file:target/log4jClient.xml
log4j.configuration = file:./@target.dir@/log4jClient.xml

The last line requires substitution of @targer.dir@ with the value "target".

The relative paths should let you avoid normalizing paths as currently done 
in the "test.prepare.logging" target in 
$CACTUS_HOME/samples/servlet/build.xml.

I have also noticed that log4j configuration in [3] does not suggest any 
logger names which might be useful in filtering out noise. There is really 
tons of it.

You can filter out some of it with the following log4j config file.

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

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

   <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%-5p %c - %m%n"/>
     </layout>

     <filter class="org.apache.log4j.filter.StringMatchFilter">
       <param name="StringToMatch" value="enter"/>
       <param name="AcceptOnMatch" value="false"/>
     </filter>

   </appender>

   <logger name="org.apache.log4j.joran.action"> <level value="INFO"/></logger>
   <logger name="org.apache.commons.httpclient.HttpParser"> <level 
value="INFO"/></logger>
   <logger name="org.apache.commons.httpclient.HttpConnection"> <level 
value="INFO"/></logger>
   <logger name="org.apache.cactus.internal.WebRequestImpl"> <level 
value="INFO"/></logger>
   <logger name="org.apache.cactus.internal.util.JUnitVersionHelper"> 
<level value="INFO"/></logger>

   <root>
     <level value="DEBUG"/>
     <appender-ref ref="CONSOLE" />
   </root>
</log4j:configuration>

It removes all messages containing the string "enter". It also sets the 
level of several loggers to "INFO" which reduces the noise they generate.

Even with the above config file the log output still contains too much 
noise. Which are the Cactus loggers that generate the most useful 
information, information that can help to follow the execution steps as 
illustrated in [2] ?

[1] http://jakarta.apache.org/cactus/integration/ant/howto_ant_cactus.html
[2] http://jakarta.apache.org/cactus/how_it_works.html
[3] http://jakarta.apache.org/cactus/integration/manual/howto_config.html

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



Mime
View raw message