Agreed. One way you could get around this is by making a (fairly simple) servlet that finds out where the log4j log file is, reads it and displays it, on request. Should not be too hard, and will be more app-server-independent and administrator-independent than any attempt to write the log file directly to the web-root.
Daniel -----Original Message----- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 16 October 2003 23:27 To: Log4J Users List Subject: RE: Making HTML log file available through web app Howdy, Even if deploy exploded (a feature servlet containers are not required to support), the server admin may configure the server such that you don't have write access under your webapp. The only directory you're guaranteed write access to by the servlet specification is javax.servlet.context.tempdir, which the container may clean on shutdown, so you don't want to put your logs there. Deciding where logs go is a server administrator decision: leave it up to he/she by allowing them to configure something easily in web.xml or better yet, a server configuration entry you pick up via an env-entry in your web.xml file. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Doubleday, Dennis [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 16, 2003 6:07 PM >To: 'Log4J Users List' >Subject: RE: Making HTML log file available through web app > >No, different servers for different customers. > >Yes, OK, I suppose I can have a different log4j.xml for each app server and >a server-specific Ant deployment target. > >What should the relative file location be, though, if I deploy an EAR file >to the server and there is no exploded context-relative directory to write >the logs to? Will I have to deploy exploded in order for that to work? Is >that server-dependent? > > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 16, 2003 5:57 PM >To: [EMAIL PROTECTED] >Subject: RE: Making HTML log file available through web app > > >This isn't necessarily app-server independent, but you can probably can >take >advantage of variable substitution in the config file. Log4j can >substitute >system property values into the log4j config file using the Ant-like syntax >(${<system properties>}), so if your app server puts deployment-specific >information into system variables (Weblogic does), then you can use them. > >Is it really necessary to do it in a totally app-server independent manner? >It's just a matter of changing the config file. Are you running a >heterogenous set of J2EE servers? > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]