Note that the settings in web.xml can be overridden at runtime.
For instance, without the customer every modifying the .war archive, they can set a custom location for logs. In Tomcat, it would work like this...
in web.xml
<context-param>
<param-name>log-location</param-name>
<!-- provide a default value -->
<param-value>WEB-INF/logs</param-value>
</context-param>
in server.xml or, beter yet, in a context configuration file
<Context path="/myapp" docBase="myapp.war" >
<Parameter name="log-location" value="/my/custom/log/location" />
</Context>
I think I got the syntax right. Not positive. Double check with the Tomcat docs before using the above.
So, you distribute your fully self-encapsulated portable myapp.war file and the deployer has the job of doing configuration appropriate to their own needs. Not all servers will have the same server configuration, but they will all have some way to do what we just did for Tomcat. The deployer should understand this.
Jake
At 11:25 AM 2/20/2003 -0800, you wrote:
I agree. When I posted that, it was a summation of the posts that I had seen till that time.What I've been looking for is a "standard" way to configure my .war archives, such that we can call it a "true" deployable - without any interference from the users. Like someone else pointed out, the intent is to make have "configuration free" archive. I've had several instances in the past, where despite the best efforts, we ended up having to provide "instructions" to the end-user for deployment (and the worst is one you ask the end-user to open up the web.xml or some application-specific properties file that the applications reads from). Further, there are instances where certain servers do not explode the .war archive, so the end-user never gets to see those properties files themselves. Regards, Manav. ----- Original Message ----- From: "Jacob Kjome" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 8:51 PM Subject: Re: Best Logging practices > > Your question is now becoming a lot more logging-in-general oriented where > it was about logging from webapps before. I suggest you look to the > experts on the log4j-user list or, better yet, buy the book on using log4j: > > http://www.qos.ch/shop/products/clm_t.jsp > > This is loaded with information and I highly recommend getting it. It will > answer most, if not all, of your logging questions. > > Jake > > At 09:27 AM 2/20/2003 -0800, you wrote: > >Without an intent to offend anyone, I'd say majority of the posts were > >centered around what tools to use, rather than the best practices itself > >(apart from the posts of Jacob and Peter Lin). > > > >So, from what I understand: > >1. Web applications written using tomcat should have the logging path > >configurable (via the parameters in the web.xml, for example) - since the > >webapp can be run directly from the .war archive. And Steve had a remark > >about not being able to have configurable files inside the jar. > >2. While logging to a directory inside the webapp structure, its a good > >practice to check context.getRealPath("/") returns non-null first. > >3. Keep an alternative - so when logging to your file fails, use > >ServletContext.log(string) to send the message string to application log. > > > >What about, like Peter mentioned (but did not quite elaborate) log rotation? > >report generation based on logs? log backups? Also guidelines for the > >developers to separate the log messages that are errors, and log messages > >that are produced by the application as indications of the outcome of some > >task? > > > >Thanks, > >Manav. > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
