Hi Ceki,

> -----Original Message-----
> From: Ceki G�lc� [mailto:[EMAIL PROTECTED]
> Sent: mardi 11 janvier 2005 14:25
> To: Cactus Users List
> Subject: My first impressions as a Cactus user, [WAS: Log4j integration
> testing...]

First, many thanks for taking the time to provide this feedback. If everyone
was doing this we would end up with much better software for sure. I really
appreciate it.

> 
> At 11:38 AM 1/9/2005, Vincent Massol wrote:
> >Hi Ceki,
> >
> >See
> >http://jakarta.apache.org/cactus/integration/manual/howto_config.html#log
> gin
> >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.)

:-)

Good point. I have now removed the "how it works" from the main page.

> 
> 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. :-)

:-)

Why did you have to do this? I would like to understand so that I can
correct the doc.

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

Ok, I didn't know about the relative file URL feature. It should simplify
our build script.

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

For the severity, this was already there in the sample properties file: 

log4j.category.org.apache.commons.httpclient = DEBUG, cactus
log4j.additivity.org.apache.commons.httpclient = false
log4j.category.httpclient = WARN, cactus
log4j.additivity.httpclient = false

Thanks for the tip for the filter though which I had never used before.

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

I don't know from the top of my head. Would need to research this. Usually
I've found the noise not to be a problem because I always track a problem
from the place where it happens (location of stack trace in the log) to the
cause, following the methods traversed.

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

Thanks Ceki for this very useful feedback and let me know if I can help you
in your usage of Cactus

-Vincent




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to