Ceki Gülcü wrote:
> Actually, I have been using log4j out of the box in my web applications. One has to
>follow the servlet life cycle, in init() to intialize log4j and in destroy() to close
>appenders with Category.shutdown(). Logging to the console also works without any
>special steps. I am using Tomcat 3.2. Regards, Ceki
(i use tomcat 4 so i guess my comments are mainly aimed at that)
i'd say that the whole log4j infrastructre is a good solution to the problem of
logging and debugging web-apps :-) but IMHO there are a few wrinkles when it comes to
logging within a webapp...
logging to the console works but tomcat 4 sends this into catalina.out which is a bit
unsatisfactory. a better place is the servlet log for the context - but this reference
is only know at context creation time.
it's sort of natural to try to configure log4j on a per webapp basis. if you want to
use files, then you have to think about how you specify the file. it's sort of
unsatisfactory to use absolute paths (what happens when you deploy to a different
server?) but relative paths are unreliable since they aren't
relative to the base directory of the web app. if you're not expecting this behaviour,
it can be a little surprising. (it certainly surprised me before i thought about it!)
IMHO it's seems natural to log and configure on a webapp basis, configuring logging
when the context is created and destroying the created stuff when the context is
destroyed. at the same time, you can get hold of the servlet log and log categories
there if you wish and also calculate absolute paths from
webapp base relative ones to load configuration files or set-up file based logging. my
point is that you need to write extension code if that's the sort of thing you want to
do.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
