jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject Re: [proposal] Cactus Logging strategy for Cactus 1.3
Date Sat, 17 Nov 2001 19:35:06 GMT
Just one thing :
- I am not sure whether it is better to use an xml file or a properties
file. It would seem to me that the properties would be better (although I
would have liked to use the xml format :) ) for the following reason :
  - no need for an xml parser present on the classpath (although it is
highly likely you'll have one),
  - log4j's DOMConfigurator may not work with all parsers
  - there are some log4j features that we won't be able to use without the
XML format but they do not seem important for our usage
  - at the current point, the cactus configuration is very simple (only some
redirector url), nothing hierarchical, so an xml format is not really needed

Thanks
-Vincent

----- Original Message -----
From: "Vincent Massol" <vmassol@octo.com>
To: <cactus-user@jakarta.apache.org>
Sent: Saturday, November 17, 2001 7:28 PM
Subject: [proposal] Cactus Logging strategy for Cactus 1.3


> Hi,
>
> I'd like to propose a Cactus logging strategy for Cactus 1.3.
>
> Some remarks:
> * Cactus is a framework for performing unit tests and for each method to
> test, the unit test case create a new instance of the class to test (as a
> standard java object) and call the method to test. Thus, if the
application
> under test is normally performing logging (using log4j for example), the
> initialisation code for initialising the application logging subsystem
> should normally not be called during the unit tests. In other words, the
> application under test is being driven by Cactus and thus we expect the
logs
> statements to go to wherever Cactus says so. This is just to say that
> applications under test should not expect their logs to go to their own
log
> files.
>
> Strategy:
> * There are 2 Cactus Log4j configuration : one on the client side and one
on
> the server side (webapp)
> * For the server side :
> - in web.xml, we define the location of the log4j configuration file using
> <context-param> element
> - the log4j configuration data is an XML file (cactus.xml) that we
recommend
> to put in WEB-INF/
> - We initialise log4j with an AspectJ aspect. The following algorithm is
> applied :
>   - If log4j is not in the classpath, do not perform logging (use cactus
> noop logger)
>   - If log4j is present and if there is a <context-param> that defines the
> location of the config file, then use it to configure log4j
>   - If log4j is present and if there is not <context-param> that defines
the
> location of the config file, then try to find "/cactus.xml" in the
classpath
> - cactus.xml defines the log4j appenders, categories, ... By default we
> define :
>   - a default category that has a log level of INFO,
>   - a org.cactus.* category that has a log level of WARN (so that we don't
> generate huge debug logs by default)
> * For the client side :
> - we have a single cactus.xml configuration file that contains what is
> currently in cactus.properties + the log4j configuration on the client
side
> - we output the result of all test case executions in a single log file.
We
> do this by :
>   - using an NDC with the test case name to differentiate logs,
>   - set append=true for the file appender. This is needed because under
> junit, each test case runs in its own classloader and thus log4j is
> initialized once per test case and if set append to false, the result of a
> previous test case is deleted by the next test case (which is what is
> currently happening with Cactus 1.2 logs)
>   - set flush = true  for the file appender (same reason)
>   - The only question is how do I flush the log so that we won't keep the
> log result for the next run. I'm still not sure. Several possibilities :
>     - it is removed before executing the tests (by an ant task for
example)
>     - it is removed inside cactus at the very beginning (before test case
> execution). This would be done using an aspect
> - we initialise log4j with an aspect. The following algorithm is applied :
>   - If log4j is not in the classpath, do not perform logging (use cactus
> noop logger)
>   - If log4j is present and junit has been started
> using -Dcactus.config=location_of_cactus_xml then use it to configure
log4j
>   - If log4j is present and no cactus.config system property has been
> defined, then try to find "/cactus.xml" in the classpath
> - cactus.xml defines the log4j appenders, categories, ... By default we
> define :
>   - a default category that has a log level of INFO,
>   - a org.cactus.* category that has a log level of WARN (so that we don't
> generate huge debug logs by default)
>
> What do you think ? Do you like it ?
> Thanks
> -Vincent
>
> --
> Vincent Massol, vmassol@octo.com
> OCTO Technology, www.octo.com
> Information System Architecture Consulting
>
>
> --
> To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:cactus-user-help@jakarta.apache.org>
>
>


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


Mime
View raw message