jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaarle Kaila <kaarle.ka...@iki.fi>
Subject Re: [proposal] Cactus Logging strategy for Cactus 1.3
Date Sun, 18 Nov 2001 20:18:58 GMT
At 19:35 17.11.2001 +0000, you wrote:
>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 :

I have sofar not very much experience of cactus so you should
keep that in mind as you read my comments:
I believe many to be users of cactus also has little experience of it.
They would only like to write the testcases.

The idea with JUnit is to make testing of Java programs
in a way that can be used in most applications.
One thing to bear in mind here is that using JUnit should
be rather easy so that programmers accept it and don't think
of it as something too complex compared to the simple
classes they have written.

Don't make cactus too diffcult to use.


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

I would prefer a properties file for the reasons I mentioned above.
Unless you are directly working with xml you may not have an
xml-parser.

Keep in mind that older systems like weblogic 5.1 do not use xml-files.
(nor web.xml etc)

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

---------------------------------------------
Kaarle Kaila
http://www.iki.fi/kaila
mailto:kaarle.kaila@iki.fi
tel: +358 50 3725844



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