Hi Jim, ----- Original Message ----- From: "Jim Downing" <[EMAIL PROTECTED]> To: "Cactus Users List" <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]> 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, [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]>
