Hi Yoav,
Are you sure about that?
contextInitialized() get called when everything has gotten done initializing. That is, the webapp is now ready to run. So, in effect, a servlet with <load-on-startup>1</load-on-startup> will get called *before* the contextInitialized() method gets called because until that servlet completes the init(), the webapp is *not* initialized.
ServletContextListener's contextInitialized() and contextDestroyed() methods are notified at the *end* of each process of startup and shutdown, respectively. So, this only works for you if you don't use log4j in servlets which load on startup. The only way to guarantee this is to use a servlet which loads on startup and make that servlet have <load-on-startup>1</load-on-startup> and give other servlets that load on startup numbers that are higher than 1. This will guarantee that Log4j will be configured and available for all other resources in the application. I'm making one assumption here that I'm not sure I can make. I am assuming that each init() method must complete before the next servlet's init() method gets called. If that assumption is false, then all bets are off. However, in practice, I've never had a problem so far with this issue.
The contextDestroyed(), on the other hand, is a fine place to do any log4j cleanup such as calling LogManager.shutdown() to release any locks on Files if you were using, for instance, when using a FileAppender.
Jake
At 03:45 PM 12/5/2002 -0500, you wrote:
Hi,
Consider moving the log4j initialization from a startup servlet to a
ServletContextListener's contextInitialized() method. That's guaranteed
to be the first thing in your webapp that's called by the server.
Before any init() methods. And then you don't need to worry about the
possibility of a load-on-startup servlet being destroyed and reloaded by
the container (which can happen: the container is free to do this at any
time).
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Peter Lindquist [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, December 05, 2002 3:37 PM
>To: Log4J Users List
>Subject: Re: Resin with log4j (long)
>
>Thank you Rick..
>
>Log4j was being initialized in the startup servlet's init method, but
it
>wasn't technically the -first- thing that was done. Neither of the two
>preceding operations used log4j, but obviously those classes must have
>created something that does.. because the errors went away when I
bumped up
>the log4j initialization to be the first thing in the init() method.
>
>
>----- Original Message -----
>From: "Morris, Rick" <[EMAIL PROTECTED]>
>To: "'Log4J Users List'" <[EMAIL PROTECTED]>
>Sent: Thursday, December 05, 2002 1:50 PM
>Subject: RE: Resin with log4j (long)
>
>
>We had this problem for a while until we realized that the log4j
>initializer
>servlet needed to be started first. If you are using a servlet to
>initialize
>log4j, just make sure it is loaded before anything that uses log4j and
you
>should be fine.
>
>-----Original Message-----
>From: Peter Lindquist [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, December 05, 2002 2:53 PM
>To: [EMAIL PROTECTED]
>Subject: Resin with log4j (long)
>
>
>I've researched this a fair amount.. any input or suggested new
directions
>would be most appreciated.
>
>Problem: Resin starts with log4j warnings (Win2k and/or linux)
>
>Resin 2.1.5 (built Fri Oct 4 12:10:31 PDT 2002)
>Copyright(c) 1998-2002 Caucho Technology. All rights reserved.
>
>Starting Resin on Thu, 05 Dec 2002 12:29:43 -0600 (CST)
>log4j:WARN No appenders could be found for logger (root).
>log4j:WARN Please initialize the log4j system properly.
>
>
>Here's what I've got.
>
>I'm using an xml config file and the DOMConfigurator class for loading
it.
>The root logger has an appender assigned to it and the config file IS
being
>read. After these warnings are generated, log4j proceeds to load and
log
>messages according to my config file. Updating the file results in
>immediate
>new behavior.
>
>I turned on debugging for log4j (<log4j:configuration debug="true">)
and
>received the following console messages AFTER the warnings presented
>above..
>which means the warnings were printed before the config file had even
been
>read. I've reduced the output to what seemed relevant, as the whole
thing
>is
>a bit too much for the eyes.
>
>
>configFileName: C:/home/HEAD/Properties/logging.xml
>log4j: Threshold ="null".
>log4j: Retreiving an instance of org.apache.log4j.Logger.
>. . .
>log4j: Level value for root is [DEBUG].
>log4j: Desired Level sub-class: [util.PinLogLevels]
>log4j: root level set to DEBUG
>log4j: Adding appender named [MainLog] to category [root].
>http listening to *:80
>
>
>The relevant parts of my config file:
>
><log4j:configuration debug="true">
> <appender name="MainLog" class="org.apache.log4j.RollingFileAppender">
> <param name="file" value="C:/home/HEAD/logs/pinpoint.log"/>
> <param name="append" value="true"/>
> <param name="MaxFileSize" value="10MB"/>
> <param name="MaxBackupIndex" value="10"/>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d %-5p [%t] %c%x - %m%n"/>
> </layout>
> </appender>
>
> <root>
> <priority value ="DEBUG" class="util.PinLogLevels"/>
> <appender-ref ref="MainLog"/>
> </root>
>
></log4j:configuration>
>
>
>My classpath directive within resin.conf which loads the log4j.jar file
is
>associate with the web-app:
>
><classpath id='C:/home/HEAD/lib' library-dir=true/>
>
>
>Any ideas?
>
>Thank you..
>
>
>--
>To unsubscribe, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
>
>--
>To unsubscribe, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:log4j-user->[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
