8 messages in com.canoo.lists.webtestRe: [Webtest] developer info| From | Sent On | Attachments |
|---|---|---|
| Bill Milbratz | 03 Oct 2003 08:44 | |
| Siegfried Goeschl | 03 Oct 2003 10:09 | |
| Dierk Koenig | 03 Oct 2003 10:49 | |
| Aatish Arora | 03 Oct 2003 11:00 | |
| Bill Milbratz | 03 Oct 2003 13:47 | |
| Marc Guillemot | 04 Oct 2003 02:12 | |
| Dierk Konig | 04 Oct 2003 10:00 | |
| Dierk König | 04 Oct 2003 10:08 |
| Subject: | Re: [Webtest] developer info |
|---|---|
| From: | Marc Guillemot (mgui...@yahoo.fr) |
| Date: | 10/04/2003 02:12:33 AM |
| List: | com.canoo.lists.webtest |
Hi Mittie,
well done! Such a mail is a great improvment: it permits to inform developpers and non developpers on the internal happenings in webtest and permits webtest developpers and users to discuss to find the best way to improve webtest.
and as I say, it permits to discuss...;-)
- introduced log4j for a finer control of logging. The usual way of getting information should not have changed, i.e. the ant -verbose flag and the config verbose="true". The new possiblities can be found in the lib/log4j.properties file. The lib dir now needs to be on the classpath or you will get a log4j warning. I intend to further advance on this.
I wanted to suggest incorporating it but I wasn't sure of the best choice between log4j and jakarta-common-logging. The later has the advantage to allow users to choose what they really wan't to use at the end: log4j, jdk1.4 logging facilities, or something else. In a project for a client I would rather propose log4j but for a library like webtest that is used by a large number of persons on different systems, I guess that jakarta-common-logging is more flexible.
Concerning your log4j usage, I've two minors improvment suggestions: - use log4j.xml for the configuration: as xml file, it's nicer to handle - use the syntax static Logger logger = Logger.getLogger(MyApp.class); to get a logger rather than the "old" Category methods. I can perform the changes if you want, but I wanted to discuss it before (I don't want to appear as destructor of your code).
- We needed to patch the httpunit version 1.5.4 to overcome some hiccups with https. The patched class versions can be found in resources/httpunit-patches. More patches are likely to come, e.g. a patch for the file:// protocol handling.
ok for the "file:// protocol": I think it's for me. But I don't understand how you want to let it work. I thought, you would have built the folder hierarchy com/meterware/httpunit to permit to compile it and I don't see where it get compiled. Can you explain how it works?
...
Marc.