On the log4j part : I find them quite verbose sometimes but when I know what I'm
looking for, it helps me resolve the problem without having to type in print
statements and recompiling. I usually control the verbosity of the logs by setting
the log4j RootCategory debug level to info and setting the log4j Category of the
problem code to debug. This way there is not too much generated logs. Once I spot a
possible bug I'll turn on the logging for other parts of the code which might give me
more hints. Works for me =)
-----Original Message-----
From: Mike Stover <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2001 20:50:55 +0000
To: [EMAIL PROTECTED]
Subject: drastic changes
> Hi all,
> I made some potentially troublesome changes. In order to make an
> Assertion model, I needed Controllers to act more consistently. To that end,
> I created two types of controllers - logical and generative. Logical
> controllers simply change the behavior of the test. Generative controllers
> generate test samples.
>
> Previously, you could create a Web Test controller and add many UrlConfigs to
> it to create multiple test samples. This, in effect, was like saying
> UrlConfigs, which are ConfigElements, could create test samples. I've
> changed it so that this does not happen anymore - every individual test
> sample must be represented by a Web Test controller.
>
> The benefits are:
> 1. Easier to code controllers since there more common code that now lives in
> parent classes (AbstractGenerativeController, and LogicController).
> 2. Assertions can be added at one point, consistently (ie, to a Controller -
> no need for a special case dealing with UrlConfig elements).
> 3. It's not any harder to create tests - it's a one-to-one replacement of Web
> Test controllers for UrlConfigs.
> 4. Tangentially, making an image-retrieving UrlConfig or a Multipart-form Url
> now is only a matter of clicking on a checkbox
>
> The disadvantage is:
> 1. If you have previous test saved, they can be loaded into JMeter, but
> JMeter will no ignore all those UrlConfigs that you thought were test
> samples. To update your old tests, you'll have to convert the base Web Test
> controller into a LogicController (and add a UrlConfig representing the
> common data you had put into the Web Test's default Url), and then convert
> each UrlConfig into a WebTest controller with the same data.
>
> Manually, this would be a pain. I'd like to make some more automated way of
> converting old test plans into the new version. I think the best place to do
> it would be at the loading stage (when the XML is being parsed, or
> immediately following the parsing).
>
> Also, on another note, does everyone really like all the log4j debug
> statements? To be honest, they seem to mostly obfuscate the code - kind of
> like littering your code with comments everywhere. I have a hard time
> believing that many log statements is really useful (and typically, when I'm
> debugging a problem, I have to add my own print statements anyway, but I take
> them out when I'm done, mostly).
>
> --
> Mike Stover
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
__________________________________________________
Get FREE 50 MB email @ http://www.AtoZasia.com
Powered by Outblaze
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
