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]

Reply via email to