On Tue, 14 Dec 2004 17:10:44 -0800 Mark Womack <[EMAIL PROTECTED]> wrote:
Well, maybe you guys have had to solve this kind of problem before. I want
to have the log home directory in one place for jboss and another place for
tomcat.
I've never hit this requirement yet, I tend to log to a file with no path specified hence current working directory. People have to learn where the log file is at depending on their setup (dev/test/deploy) or configure it otherwise at deploy time.
So, I was mucking with some code to set the log home base
directory. The mechanism I fellback to was looking at the system
properties. If I find properties starting with "jboss" then it is jboss.
If I find properties starting with "tomcat" (not "catalina) then it is
tomcat.
But I would be interested in knowing how people have solved the log file
location problem. We also have to contend with Windows and Linux
installations, so just having a common, external directory doesn't help.
I think there have been discussions in the past on log4j-user relating to specifying the path in the log4j.properties using a system property. I guess this is only useful if you have control over the container environment.
Or
maybe I am missing something basic here. Whatever we set in the
configuration file, I want it to work in our development env, the base
deployment env, and on Windows and Linux.
It would seem simpler to me to keep the code the same but produce a separate war file per specific platform which contained a different log4j.xml file. The file appender section could even be included into a generic log4j.xml using external entities resolved at runtime.
Regards
Andy
-Mark
-----Original Message-----
From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 4:33 PM
To: Log4J Developers List
Subject: Re: o.a.log4j.servlet
Hi,
It's fairly pointless to rely on getServerInfo and similar approaches: it's
one
of the first things security-conscious server administrators customize or
spoof, as that's a recommended best practice.
Class-name-based detections (e.g.
Class.forName("org.apache.catalina.foo.bar")
for Tomcat) are also risky at best, as for example JBoss bundles Tomcat,
numerous other containers bundle Jasper, etc. But it's better than using
getServerInfo.
All of this should be done really as a last resort -- the servlet classes in
log4j should be (and I think are, so I'm wondering where you see a need)
designed to the Servlet Specification...
Yoav
--- Andy McBride <[EMAIL PROTECTED]> wrote:
>or
>Also, does anyone know if there is a way to >programmatically detect the web
>container the web app is running under? I am seeing a >need to have
>different behavior between JBoss and Tomcat, and I was >just wondering if
>there is a standard way to detect this.
>
>-Mark
>
Mark,
The ServletContext has a getServerInfo() method which according the javadoc:
Returns the name and version of the servlet container on which the servlet is running. The form of the returned string is servername/versionnumber. For example, the JavaServer Web Development Kit may return the string JavaServer Web Dev Kit/1.0. The servlet container may return other optional information after the primary string in parentheses, for example, JavaServer Web Dev Kit/1.0 (JDK 1.1.6; Windows NT 4.0 x86)
So the output "should" be easy to parse but I wouldn't like to put money on every server vendor complying with this contract!
I must admit I'm curious to know what need you forsee to have to accomodate different behaviour depending on container vendor? The main point of the J2EE spec is to provide a vendor-neutral API for applications to code to. The cost of maintaining specific behaviour dependant on server vendor would be huge with the current abundance of server vendors.
Cheers
Andy
The information contained in this e-mail is intended only for the personentity to which it is addressed and may contain confidential and/ore-mail,
privileged material. If You are not the intended recipient of thisthe use of this information or any disclosure, copying or distribution isGroup
Prohibited and may be unlawful. If you received this in error, please
contact the sender and delete the material from any computer. The views
expressed in this e-mail may not necessarily be the views of The PCMSplc and should not be taken as authority to carry out any instruction
contained.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The information contained in this e-mail is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If You are not the intended recipient of this e-mail, the use of this information or any disclosure, copying or distribution is Prohibited and may be unlawful. If you received this in error, please contact the sender and delete the material from any computer. The views expressed in this e-mail may not necessarily be the views of The PCMS Group plc and should not be taken as authority to carry out any instruction contained.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
