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.
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. 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. I'll check in some changes to the InitShutdownController later this week. -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]
