-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 5:41 PM, Jane Muse wrote:
We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE.
I sent the contents of CATALINA_BASE/conf/context.xml in the email
below.
Great. It's probably not necessary to comment-out the
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Disable class monitoring for reloading container classes
It's probably not necessary to comment-out the WatchedResource
as the context should not be reloadable if you set reloadable=true,
Is that a typo? Do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 10/14/2010 11:18 AM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Disable class monitoring for reloading container classes
It's probably not necessary to comment-out
!
Thanks much,
Jane
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, October 14, 2010 7:54 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/14/2010 11:42 AM, Jane Muse wrote:
Chris wrote:
It's probably not necessary to comment-out the WatchedResource
We didn't change WatchedResource in context.xml from how it was
installed in tomcat 6.0.18. The default is commented
a fix out.
Thanks to everyone for all the help.
Jane
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, October 12, 2010 11:08 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring
List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 11:09 AM, Jane Muse wrote:
My understanding from the docs is that reloading=false means you
can't drop in a war file while tomcat is running and expect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:40 PM, Jane Muse wrote:
Thanks for the java program Chris, I ran it on the version of the O/S
where we get the problem and got results that show a last modified
date that differs by one hour when the time changes due to DST.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:51 PM, Jane Muse wrote:
I found that reloadable=false does not suppress tomcat from watching
if files change in WEB-INF/lib, even though the docs say it does:
Please log a bug. Note that bugs logged against old versions of
, 2010 11:26 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:51 PM, Jane Muse wrote:
I found that reloadable=false does not suppress tomcat from watching
if files change in WEB-INF
From: Jane Muse [mailto:jm...@aldon.com]
Subject: RE: Disable class monitoring for reloading container classes
Here's my context.xml:
!-- WatchedResourceWEB-INF/web.xml/WatchedResource --
That may not be illegal syntax for XML, but it certainly is confusing. Better
to do
and
restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to
all.
Jane
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Wednesday, October 13, 2010 12:57 PM
To: Tomcat Users List
Subject: RE: Disable class monitoring for reloading container classes
timezones (or DST settings).
Jeff
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, October 13, 2010 1:21 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE
List
Subject: RE: Disable class monitoring for reloading container classes
That was me in another thread. Here's what I stated:
It just occurred to me that I don't think anyone's asked if these are
net-mounted file systems. I've seen this timestamp-shifting before, but
only on net-mounted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/10/2010 9:09 AM, André Warnier wrote:
What would be really nice, is if someone wrote a quick Java equivalent
to the perl script I submitted.
See below. There's actually more code than absolutely necessary, but
it's more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 12:02 AM, Jane Muse wrote:
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
I meant that it would be nice if the log said something like File X
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 11:09 AM, Jane Muse wrote:
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.
No, Context reloadable=false (reloading is meaningless) means
://security.it.ray.com/news/2007/zipfiles.html
Should you have any questions or difficulty with these instructions, please
contact the Help Desk at 877.844.4712
---
Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Disable class monitoring for reloading container
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Disable class monitoring for reloading container classes
The timestamp of the file should be /the/ timestamp for the
file, and shouldn't be affected by the current DST settings
to IBM's O/S,
or Oracle's JVM 8-)
Thanks.
Jane
-Original Message-
From: Jane Muse [mailto:jm...@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
Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Saturday, October 09, 2010 7:19 AM
To: Tomcat Users List; Jane Muse
Subject: Re: Disable class monitoring for reloading container classes
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject
Jane Muse wrote:
André,
thanks for the perl program. I tried it and got
qsh: 001-0019 Error found searching for command showmodified.pl. No such path or directory.
You may need to adjust the first line of the program, to point to the executable perl
interpreter.
Use which perl to
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Disable class monitoring for reloading container classes
thanks for the perl program.
I would not introduce yet another variable into situation, since perl is not
involved in any way with your Tomcat installation, and we don't know how
On 08/10/2010 01:11, Jane Muse wrote:
This happens with both DST and standard time changes. What's interesting
is if we go back in time to Oct 29 2006, it does not occur. From March
2007 forward, every fall and spring we get the error when the
application reloads. The DST time change rules
-
From: Pid [mailto:p...@pidster.com]
Sent: Thursday, October 07, 2010 8:23 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
On 06/10/2010 20:39, Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container
Jane Muse wrote:
If I changed the system time zone not to change with daylight savings
time, then it would be off by an hour. I don't think our customers would
like that. Or am I misunderstanding your comment?
Maybe Pid's comment was partly tongue-in-cheek.
You did not misunderstand, but of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 10/8/2010 4:44 AM, Mark Thomas wrote:
On 08/10/2010 01:11, Jane Muse wrote:
This happens with both DST and standard time changes. What's interesting
is if we go back in time to Oct 29 2006, it does not occur. From March
2007 forward,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 10/8/2010 4:44 AM, Pid wrote:
On 08/10/2010 01:19, Jane Muse wrote:
If I changed the system time zone not to change with daylight savings
time, then it would be off by an hour. I don't think our customers would
like that. Or am I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 10/7/2010 5:52 PM, Pid wrote:
On 07/10/2010 22:30, Christopher Schultz wrote:
If the above logic is the actual implementation, then the only time
you'd have a problem is when you've deployed a webapp during the window
covered by the
Christopher Schultz wrote:
...
Technically speaking, the modification date isn't checked against the
context startup date it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 2:12 PM, André Warnier wrote:
0 1 2 3 4 5
!--!--!x-!--!x-! ... (you get
the idea)
At time t1, nothing has changed, and nothing happens.
At
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 2:12 PM, André Warnier wrote:
0 1 2 3 4 5
!--!--!x-!--!x-! ... (you get
the idea)
At time t1, nothing has changed,
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, October 08, 2010 3:56 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8
in a later version (I'm at 6.0.18)?
Many thanks,
Jane
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, October 08, 2010 8:07 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 5:20 PM, André Warnier wrote:
In that case,
- Jane's experience is still incomprehensible
- the possible bug I mentioned cannot happen
+1 +1
- but the logic used by Tomcat seems wasteful : aren't these a lot of
files for
-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
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Disable class monitoring for reloading container classes
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
am. See my first
email in this thread.
Thanks.
Jane
-Original Message-
From: Christopher Schultz [mailto:ch...@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
Jane Muse wrote:
André - you are correct. We actually modified autoDeploy attribute on the
Host element to false,
and not reloadable in the application context xml, and then it worked on IBM
I V7R1.
Your 3rd point below is probably the key to why it works on one version of the O/S and
not
On 06/10/2010 20:39, Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can disable
class reloading for the context with reloadable=false?
: André Warnier [mailto:a...@ice-sa.com]
Sent: Thursday, October 07, 2010 3:26 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
Jane Muse wrote:
André - you are correct. We actually modified autoDeploy attribute
on the Host element to false
Jane Muse wrote:
..
The reason why there's a problem when the application gets reloaded is due to we are
loading a JNI native library that the application requires. According to the following
link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more
than one class
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/6/2010 3:39 PM, Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can disable
On 07/10/2010 21:34, André Warnier wrote:
Jane Muse wrote:
..
The reason why there's a problem when the application gets reloaded is
due to we are loading a JNI native library that the application
requires. According to the following link, section 11.2.4, the JVM does
not allow a JNI native
On 07/10/2010 22:30, Christopher Schultz wrote:
Jane,
On 10/6/2010 3:39 PM, Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can
.
Thanks much,
Jane
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Thursday, October 07, 2010 2:52 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
On 07/10/2010 22:30, Christopher Schultz wrote:
Jane,
On 10/6/2010 3:39 PM, Jane
07, 2010 8:23 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
On 06/10/2010 20:39, Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations
Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can disable
class reloading for the context with reloadable=false? I'm using
tomcat
Subject: Re: Disable class monitoring for reloading container classes
Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can
disable class
49 matches
Mail list logo
