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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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, [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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
