Hi Peter, Thanks a lot for the response.
> here are some other considerations. For some of the > projects I've worked on in the past, there were > established directories for logs. Therefore I used > log4j to write my logs asynchronisly. Could you elaborate on "established directories"? I assume these directories were within your webapp context. If yes, then what if the application is deployed onto a server that does not explore your .war file? Secondly, there are instances where, thought the application is deployed correctly, there are no write permissions to that directory - how did you resolve such a situation? Finally, at times there are log files that are generated as a result of certain user action, not necessarily errors, but these have to be made available to the user as information. Would you store them into the same directory as other log files? Then there are other issues of such log files increasing in size and number continuously, and log rotation as well as backup. Any ideas about that? > logging isn't as simple as "write stuff to file". You > have to take into consideration other things like how > are the logs backed up, when are reports generated, > and other system administration processes. Oh, I agree to that. Since the advent of Log4J, I've seen the logging process to be more standardized, and the though there might be one-off incidents of literally anything being logged, there is some level of sanity. Though yes, log backup, report etc still are prevalent issues. > I typically stick configuration information in > web.xml, if the application is meant to be a > deployable web app in .war format. one thing to keep > in mind is what happens if your log fails, you will > want to direct the exceptions to the application log > by passing it to ServletContext.log(string). In some situations, system administrators at the customer's facility insist they should know what directories your application shall write to, and that this directory can be changed, if required for them (say, you develop the application and its deployed on a cluster, and they might want to change this path). You might stick this path in web.xml but then again, there is no guarantee the web app will be exploded. Thanks, Manav. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
