You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Vincent Massol <vm...@octo.com> on 2001/11/17 20:28:45 UTC
[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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] Cactus Logging strategy for Cactus 1.3
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: <al...@dsl.ab.ca>
To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
<vm...@octo.com>
Sent: Monday, November 19, 2001 7:59 PM
Subject: Re: [proposal] Cactus Logging strategy for Cactus 1.3
> Hi,
>
> I like the suggestions so far.
>
good :)
> What is the expected initialization sequence if the user creates a
> log4j Category instance?
>
> Will the Cactus initializer always run before the log4j initializer?
> After? Order dependent?
>
> A well defined ordering is nice to have.
>
The order is the following :
1/ Initialization is always performed by Cactus first
2/ The application to test should not initialise log4j. If it does, log4j
will be reinitialized with the application parameters. It means that the
cactus appenders won't be defined and you'll see a warning on the console
saying that log4j cannot find the appender for category org.apache.cactus.
Note: Solving 2/ is not possible with Log4j 1.1.x (apart from using
Hierarchy but then your application under test needs to be coded in a
certain way, which won't work for us). However, it is possible with Log4j
1.2 (in alpha or beta) by using the notion of Repository.
>
> Alvin.
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] Cactus Logging strategy for Cactus 1.3
Posted by al...@dsl.ab.ca.
Hi,
I like the suggestions so far.
What is the expected initialization sequence if the user creates a
log4j Category instance?
Will the Cactus initializer always run before the log4j initializer?
After? Order dependent?
A well defined ordering is nice to have.
Alvin.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] Cactus Logging strategy for Cactus 1.3
Posted by Vincent Massol <vm...@octo.com>.
Several interesting points here Kaarle :
* "should keep cactus simple". Indeed ! I'd like logging to be completely
transparent for cactus end users as this is an internal feature. This is
what we have been doing so far and I'd like to keep this. However, we've
received quite a lot of emails on the mailing list regarding issues with
logging either in test cases or in the application to tests.
* "properties file for configuration". I agree. let's keep it this way.
* "no web.xml". This will not be supported as Cactus supports Servlet Api
2.2 onward only (and not previous api where web.xml did not exist).
Thus, in order to keep it simple, I'd like to bring the following
modification to the proposal :
* no <context-param> entry in web.xml. _If_ a log4j configuration file is
provided on the server side (as opposed to cactus using its default one),
then it would have to be placed under WEB-INF and be named
cactus_server.properties. Of course cactus_server.properties stays optional
(there will be a default one with default logging configuration bundled in
the cactus.jar) and you'll only have to provide one if you wish to tune
cactus logging.
* name of config file file on server side is ! cactus_server.properties and
name on client side is : cactus_client.properties. This should prevent a FAQ
"should I put cactus.properties on the client side or on the server side ?".
Version 1.3 will continue to support cactus.properties but will deprecate
it.
What do you think ?
-Vincent
----- Original Message -----
From: "Kaarle Kaila" <ka...@iki.fi>
To: "Cactus Users List" <ca...@jakarta.apache.org>
Sent: Sunday, November 18, 2001 8:18 PM
Subject: Re: [proposal] Cactus Logging strategy for Cactus 1.3
> 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" <vm...@octo.com>
> >To: <ca...@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:
> ><ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> ---------------------------------------------
> Kaarle Kaila
> http://www.iki.fi/kaila
> mailto:kaarle.kaila@iki.fi
> tel: +358 50 3725844
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] Cactus Logging strategy for Cactus 1.3
Posted by Kaarle Kaila <ka...@iki.fi>.
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" <vm...@octo.com>
>To: <ca...@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:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
---------------------------------------------
Kaarle Kaila
http://www.iki.fi/kaila
mailto:kaarle.kaila@iki.fi
tel: +358 50 3725844
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] Cactus Logging strategy for Cactus 1.3
Posted by Vincent Massol <vm...@octo.com>.
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" <vm...@octo.com>
To: <ca...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: wm=no[proposal] Cactus Logging strategy for Cactus 1.3
Posted by Nicholas Lesiecki <ni...@eblox.com>.
It's a little late for me to weigh in, but Vincent is right on the money.
Cactus users shouldn't need to know about the aspects in the system (any
more than they need to know what AbstractTestCaller does). Aspects are very
powerful, and they are ideal for doing method logging (in fact this is one
of the beginning examples on aspectj.org).
Also Cactus now serves a role in educating developers who do want to dig
into the aspects about the AspectJ extension :).
I'm 100% behind aspects.
Cheers,
Nick
-----Original Message-----
From: Vincent Massol [mailto:vmassol@octo.com]
Sent: Tuesday, November 20, 2001 1:48 PM
To: Cactus Users List
Subject: Re: wm=no[proposal] Cactus Logging strategy for Cactus 1.3
Hi Jim,
----- Original Message -----
From: "Jim Downing" <ji...@pobox.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
<vm...@octo.com>
Sent: Tuesday, November 20, 2001 10:20 AM
Subject: Re: wm=no[proposal] Cactus Logging strategy for Cactus 1.3
> Hi,
>
> I'm absolutely agree that having a unified log will save a lot of pain, my
only concerns are around AspectJ. Bear in mind that I've only had the
chance to take a cursory look at it, so I'm probably just in need of some
education.
>
> Does the use of AspectJ mean putting non-standard code in our production
classes, so they can be tested smoothly? This worries me, I would prefer our
active code to be completely ignorant that the test code even exists (I know
this is a debatable point anyway...). It's also 'another thing to learn' for
our engineers.
No, not really. The only "non-standard" code is in the source code itself.
What happens is that in Cactus build process, we use ajc (the aspectj
compiler) instead of javac. It transforms the aspects into standard java
code and then compiles it. It means that the generated cactus jar contains,
of course, standard java code.
In summary :
- if you are a Cactus user, there is no impact to you (apart from having to
put in your classpath an additional jar : aspectjrt.jar, which is 23Ko big)
- if you are a Cactus developer or want to build cacus from the sources,
you'll simply need to have the ajc ant task as part of Ant (i.e. you'll have
to put aspectjtools.jar in your %ant_home%/lib directory. But you don't even
need to understand the syntax unless you want to modify the few aspects. At
last, the aspects are in separate java classes (files). So, no worries ...
:)
>
> Is there no way around this in standard java?
Yes, there are always solution ... Even in assembly language, it is possible
to implement it ! :-)
For logging entries, exits and return values of methods, the solution is to
put log statements :
- after each method declaration
- at then end of each method
- wherever there is a call to a method
That's just an example. The goal of Aspects is to simply express "patterns"
(they are called aspects) that are common to a certain number of
classes/methods. It is a very powerful way to express that. Whereas the
logging I mentionned would require about 1000 lines of code for Cactus to be
done consistently everywhere, it only requires a few lines (about 5) using
an Aspect ... :)
It is also the first time I'm using Aspects and I was curious to see how
well they work. I have some interesting visions for using aspects to provide
more powerful integration testing in the future for Cactus and wanted to try
it on something non critical (such as internal cactus logging).
What do you think ?
Cheers,
-Vincent
>
> cheers,
> Jim
>
> On Sat, Nov 17, 2001 at 07:28:45PM -0000, Vincent Massol wrote:
> > 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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: wm=no[proposal] Cactus Logging strategy for Cactus 1.3
Posted by Vincent Massol <vm...@octo.com>.
Hi Jim,
----- Original Message -----
From: "Jim Downing" <ji...@pobox.com>
To: "Cactus Users List" <ca...@jakarta.apache.org>; "Vincent Massol"
<vm...@octo.com>
Sent: Tuesday, November 20, 2001 10:20 AM
Subject: Re: wm=no[proposal] Cactus Logging strategy for Cactus 1.3
> Hi,
>
> I'm absolutely agree that having a unified log will save a lot of pain, my
only concerns are around AspectJ. Bear in mind that I've only had the
chance to take a cursory look at it, so I'm probably just in need of some
education.
>
> Does the use of AspectJ mean putting non-standard code in our production
classes, so they can be tested smoothly? This worries me, I would prefer our
active code to be completely ignorant that the test code even exists (I know
this is a debatable point anyway...). It's also 'another thing to learn' for
our engineers.
No, not really. The only "non-standard" code is in the source code itself.
What happens is that in Cactus build process, we use ajc (the aspectj
compiler) instead of javac. It transforms the aspects into standard java
code and then compiles it. It means that the generated cactus jar contains,
of course, standard java code.
In summary :
- if you are a Cactus user, there is no impact to you (apart from having to
put in your classpath an additional jar : aspectjrt.jar, which is 23Ko big)
- if you are a Cactus developer or want to build cacus from the sources,
you'll simply need to have the ajc ant task as part of Ant (i.e. you'll have
to put aspectjtools.jar in your %ant_home%/lib directory. But you don't even
need to understand the syntax unless you want to modify the few aspects. At
last, the aspects are in separate java classes (files). So, no worries ...
:)
>
> Is there no way around this in standard java?
Yes, there are always solution ... Even in assembly language, it is possible
to implement it ! :-)
For logging entries, exits and return values of methods, the solution is to
put log statements :
- after each method declaration
- at then end of each method
- wherever there is a call to a method
That's just an example. The goal of Aspects is to simply express "patterns"
(they are called aspects) that are common to a certain number of
classes/methods. It is a very powerful way to express that. Whereas the
logging I mentionned would require about 1000 lines of code for Cactus to be
done consistently everywhere, it only requires a few lines (about 5) using
an Aspect ... :)
It is also the first time I'm using Aspects and I was curious to see how
well they work. I have some interesting visions for using aspects to provide
more powerful integration testing in the future for Cactus and wanted to try
it on something non critical (such as internal cactus logging).
What do you think ?
Cheers,
-Vincent
>
> cheers,
> Jim
>
> On Sat, Nov 17, 2001 at 07:28:45PM -0000, Vincent Massol wrote:
> > 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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>