Hi all,
Introduction:
Cactus is growing ... :)
The code is still quite simple and of a reasonable size (a few Kbytes) ...
but the difficulty when adding a new feature or correcting a bug is to
ensure that it will run on all (most) servlet engines (even though the
Servlet API is a spec, there are some differences in behaviour ... :( ).
Proposal:
I'd like to use a logging framework (log4j) and include calls to logging
methods inside Cactus. I had not done this at first because the framework
was really small and I did not want to make it harder on the users ... Now,
I am asking the question again ...
The pros are :
P1- It is easier for all committers to see what's happening by turning the
log on (debug severity) because they're making changes to the code
P2- It is also good for users as they can turn the log on and email the log
file when they have a problem
The cons are :
C1- There is an additional jar file (log4j-core.jar) that need to be in the
runtime classpath (both on the client side and on the server side)
C2- There is an additional properties file that need to be in the server
side classpath (cactus_server.properties) which contains logging
configuration parameters (the cactus.properties would be renamed
cactus_client.properties and will also contain additional properties for the
log configuration)
Note: I have already set it up on my local machine (not in CVS yet). I have
written a simple facade to Log4j, changed some build files and used it in a
class to test it. I don't see it as a big burden but really I'd like to have
your opinion on this.
Other solutions :
S1- Have 2 distributions : one without logging (this means different cactus
jar but maybe also different build.xml files) and one with. Users/committers
will be able to choose the one they want to work with. This will complexify
a bit more the Cactus build mechanism (which users do not see but which
committers do see).
S2- Do not add logging at all. I think this is going to be a problem in the
long run. However, we could also say that we wait until JDK 1.4 is the norm
and use it's logging API. The problem is we will probably have to wait at
least 2 years before everyone uses JDK 1.4 .... So I don't think it is a
viable solution. Maybe we could retrofit the JDK1.4 logging implementation
into a JDK 1.2 or 1.3 (as they did for the Collection classes with JDK 1.1)
...
S3- Do our own custom logging, i.e. write 2-3 simple classes that log to a
file with a debug switch ... Better yet, find one that is open source with a
correct license (I'm sure there are tens of these within Jakarta ...) and
copy the classes in our src tree. It won't be as flexible as the Log4j
framework but it may be functional enough. Does anyone know of such a
framework which aim is to be included in the source tree and not used as an
external libary ?
Note: I find it stupid that we should be discussing these kind of things
when there is a nice and powerful logging framework available (Log4j) ! It
seems it is a more general problem with the java platform regarding the cost
of using a external library ...
Another idea that comes to me suddenly :
S4- Write a facade for Log4j (already written) and do not make use of any
Log4j call directly. Use reflection instead so that it would compile even if
the log4j jar is not in the classpath. Provide in the facade code a noop
implementation of log4j so that at runtime the log statements in the code
would simply do nothing ... For normal users, they have nothing to do and
for users who want logging they'll have to provide a log4j jar. Hum .... I
could also remove the log configuration properties file by putting them in
the commons-cactus.jar file and simply add a property to the existing
cactus.properties file like : "debug = yes | no"
Tell me what you think !
Thanks a lot.
Vincent.
