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, [EMAIL PROTECTED]
OCTO Technology, www.octo.com
Information System Architecture Consulting
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
