Quoting Mark Womack <[EMAIL PROTECTED]>:
> Jake,
>
> I have a log4j configuration file per web application, so the appender
> settings, etc are per web app. I am trying to control where the files for
> each web app are located. It is kind of whacked, but I have been convinced
> by Yoav and Andy that having some mechanism to allow for external
> configuration is the right way to go.
>
Ok. I guess what it seemed like you were talking about was a config file for
the appserver. If it is per/webapp, then the InitShutdownController will
provide you with everything you need. More below...
> One thing I noticed with the default behavior in InitShutdownController is
> that if you deploy using a war file, then the WEB-INF/log directory
> typically ends up in the temp directory the container (like jboss) uses to
> expand/explode the war file. Tracking down the location can be a bit
> tricky. Can't think of anything better there though.
>
Well, that's why it is a default. I don't have the javadoc in front of me, but
I think it is documented. If one cares enough to have the files be located in
a particular location, then one can define the "log4j-log-home" context param,
and generally override it in Appserver-specific config files. For instance, in
Tomcat, you can override a context param by adding the following to you Context
Configuration File...
<Context ...>
<Parameter name="log-log-home" value="/path/to/log/directory" override="false"
description="location for Log4j-generated log files"/>
</Context>
Note that the override="false" means that value in the web.xml does not override
this setting. Sort of backward thinking, in my opinion, but that's the way
they defined it.
> I was also thinking that it would be good if the code that reads the
> log4j-log-home context parameter value could use OptionConverter to
> substitute system properties before attempting to verify/create the
> directory. That way system properties could be used in the web.xml context
> parameter as well as the log4j config file itself.
>
You mean something like setting log4j-log-home to something like
"${catalina.home}/logs" and then ${catalina.home} gets expanded before being
applied to the "[MyApp].log.home" property? Sounds intersting as long as
${catalina.home} is set from something analogous to the <Parameter> element in
the Context Configuration File rather than setting it in the web.xml file.
> I'll check in some changes to the InitShutdownController later this week.
>
Please explain further before you do this if my understanding (above) doesn't
match up with what you are thinking.
BTW, did you consider anything that I wrote (below) about
ServletContextLogAppender? All you have to know to configure it is the context
path, such as "/Myapp" and you define the log file for your servlet context at
the appserver level.
Jake
> -Mark
>
> > -----Original Message-----
> > From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 14, 2004 6:52 PM
> > To: Log4J Developers List
> > Subject: RE: o.a.log4j.servlet
> >
> > At 05:10 PM 12/14/2004 -0800, you 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. 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.
> > >
> >
> > Hi Mark,
> >
> > For appserver logging, wouldn't you be putting the config file in the
> > classpath of the server? And if you do that, wouldn't you already know
> > which appserver you were configuring? If you know, then you just use the
> > system property that the appserver sets up as its "home" property. For
> > example, under Tomcat, you'd put your config file in common/classes. Then
> > for any FileAppender in your config file, you'd point the standard log
> > file
> > location like so...
> >
> > <param name="activeFileName" value="${catalina.home}/logs/localhost.log"/>
> >
> >
> > Tomcat sets the ${catalina.home} system variable at boostrap time, so
> > Log4j
> > should have access to it by the time it initializes. The same should be
> > true for JBoss or any other server.
> >
> > >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.
> > 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.
> > >
> >
> > The above should work anywhere. BTW, as far as file locations for webapp
> > logging, the ServletContextLogAppender can solve that nicely by logging
> > all
> > output to the server's defined context log. I've found some odd issues
> > with this, however, using Log4j-1.3 and Tomcat-5.5.x. The appender gets
> > called just fine, but the logging never shows up in the context file
> > defined by the server's Log4j config; that is, if I am using a single
> > Log4j
> > instance in common/lib along with the ContextJNDISelector. If I put
> > log4j.jar in WEB-INF/lb as well, then it seems to work ok... most of the
> > time. I haven't had time to track this down, but if the functionality
> > sounds good to you and you care to do debugging, check it out in the
> > sandbox. Oh, I just remembered, I have modified the sandbox locally to
> > work with Log4j-1.3. I'll try to check that in sometime tonight.
> >
> > Jake
> >
> >
> > >-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:
> > >
> > >>
> > >> >
> > >> >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
> > 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]
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >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]
>
>
> ---------------------------------------------------------------------
> 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]
