tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Muse" <JM...@aldon.com>
Subject RE: Disable class monitoring for reloading container classes
Date Sat, 09 Oct 2010 15:09:23 GMT
> I have reloading="false" and autoDeploy="false" set in the context.xml

> and server.xml.

That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't
using the server.xml you think it is using.

My understanding from the docs is that reloading="false" means you can't
drop in a war file while tomcat is running and expect it to deploy.
reloading="false" means tomcat is not listening / watching if something
changes in WEB-INF/classes or WEB-INF/web.xml, and reload if there's a
change. If that's what these mean, then we don't need them. This is a
production environment and we tell our customers to bring down tomcat,
delete the app directory under /WEBAPPS, and then drop in a war file if
something changes. If they want to do development they should know how
to change the properties, etc. 

If I'm not understanding what autoDeploy and reloading mean, please
correct me. I'm now planning to ship the app with these settings, so I
hope it works!

We don't have "WatchedResource" set anywhere either. If anyone knows of
a way to suppress tomcat from watching if something in WEB-INF/lib has
changed, I think that might work here. But apparently tomcat is hard
wired to reload if it thinks there's a change in that directory. I'm not
sure if that would be considered a bug in the O/S, or the JVM, or if
tomcat can be made to suppress watching this, similar to what the
autoDeploy and reloading settings provide. Let's put it this way, it
would be a lot easier to get a change made to tomcat than to IBM's O/S,
or Oracle's JVM 8-)

Thanks.

Jane
 

-----Original Message-----
From: Jane Muse [mailto:JMuse@aldon.com] 
Sent: Friday, October 08, 2010 9:03 PM
To: Tomcat Users List
Subject: RE: Disable class monitoring for reloading container classes

Chris wrote:

<It's too bad the
<log doesn't show the old timestamp versus the new one. 

The log shows the timestamp for the file

Resource
> '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22
> 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO 
> ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.core.StandardContext - Reloading this Context has 
> started

Are you referring to the timestamp of the O/S? The statement right after
the one above in the log: "Reloading this Context has
> started"
only displays when the time changes from 01:59:59 to 03:00 am. See my
first email in this thread.

Thanks.

Jane




-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Fri 10/8/2010 6:29 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jane,

On 10/8/2010 7:40 PM, Jane Muse wrote:
> <Chris wrote:
> 
> <Jane, if you increase your logging level to DEBUG, you should be able

> to see the modified() method being called, and it <should tell you 
> what resource is triggering the reload in the webapp's log file.
> 
> I set the system date to: 11/07/10 at 1:53:00 and started tomcat. At 
> 2:00 the time changes to 01:00, and the following statements in the 
> log show the resource that was modified:
> 
> DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.loader.WebappClassLoader - modified() DEBUG 
> ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.loader.WebappClassLoader - modified() DEBUG 
> ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.loader.WebappClassLoader -   Resource
> '/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22
> 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010 INFO 
> ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.core.StandardContext - Reloading this Context has 
> started DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.loader.WebappClassLoader - 
> loadClass(org.apache.struts.action.RequestProcessor, false)
> 
> When the time fell back 1 hour, the modified time for ant-1.6.5.jar 
> also showed as changed to 1 hour prior to previous timestamp, and that

> prompted the reload.

Thanks for testing this: your experience is very weird. It's too bad the
log doesn't show the old timestamp versus the new one. Would you be
willing to patch Tomcat to show both timestamps?

The timestamp of the file should be /the/ timestamp for the file, and
shouldn't be affected by the current DST settings. The timestamp for the
file itself might be affected by the current DST setting when you
/touch/ it, but not when you do a simple stat() call.

> I have reloading="false" and autoDeploy="false" set in the context.xml

> and server.xml.

That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't
using the server.xml you think it is using.

> Does this look like a tomcat bug, if so are you aware if it's been 
> fixed in a later version (I'm at 6.0.18)?

Wow. That version is 3 years old: it's time to upgrade. :)

I couldn't see anything in the changelog
(http://tomcat.apache.org/tomcat-6.0-doc/changelog.html) that seems
likely, but I didn't read it in detail; that's a lot of versions to read
through. You might want to read it yourself to see if anything seems
applicable, but also to determine if there are any changes that would
prohibit you from upgrading.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyvxXEACgkQ9CaO5/Lv0PCtFgCfWU7ffkBC6KWQFWB4CWm6o5mK
tisAoLf5eLxFrKkaR8QKezxjfPtTllcF
=SlGt
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message