RE: Class cast exception when starting tomcat 7.0.1
Who says I was using a 3 year old unreleased level? I had started out with Tomcat 7.0.41 and when I got the class cast exception, I tried an easier migration - Tomcat 6.0.18 to 7.0.10. I downloaded 7.0.10 from the archives. As I said, the problem was due to using catalina.jar in my WEB-INF lib, and not due to using 7.0.10. JMuse -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Wednesday, June 12, 2013 3:18 PM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 From: Jane Muse [mailto:jm...@rocketsoftware.com] Subject: RE: Class cast exception when starting tomcat 7.0.1 Problem was solved by removing an old catalina.jar for WEB-INF/lib. The fact that you had a Tomcat-supplied jar in WEB-INF/lib is even scarier than using a three-year-old unreleased level. Tomcat-supplied jars must *NEVER* be placed anywhere other than in Tomcat's lib directory. Sounds like you need to do a comprehensive audit of your webapp development and deployment process. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
Just saying, I wasn't using a 3 year unreleased version. Maybe a 3 year version, yes. Here's my original email: I'm getting a class cast exception when starting up tomcat 7.0.1. I've migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly to 7.0.4. The error is: -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, June 13, 2013 8:52 AM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 From: Jane Muse [mailto:jm...@rocketsoftware.com] Subject: RE: Class cast exception when starting tomcat 7.0.1 Who says I was using a 3 year old unreleased level? Your subject line. I tried an easier migration - Tomcat 6.0.18 to 7.0.10. The logic of that completely escapes me. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
In the archives I thought the only unreleased versions would be specified beta. Please let me know if this is not the case. Thanks. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, June 13, 2013 9:25 AM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 From: Jane Muse [mailto:jm...@rocketsoftware.com] Subject: RE: Class cast exception when starting tomcat 7.0.1 Just saying, I wasn't using a 3 year unreleased version. Maybe a 3 year version, yes. Here's my original email: I'm getting a class cast exception when starting up tomcat 7.0.1. I've migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly to 7.0.4. The error is: Exactly. You referenced only 7.0.1 (never released) and 7.0.4, which never made it out of beta. You never told us that you meant 7.0.10 and 7.0.41 until today. We can't read your mind, only what you actually write. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
I had catalina.jar in WEB-INF/lib. It's needed because we have an implementation of Realm to store an encrypted tomcat password users enter in the webapp. If I remove it and add the catalina.jar from tomcat_home/lib to the classpath, I have to change the signature from org.apache.catalina.realm.RealmBase.Digest(String, String) to org.apache.catalina.realm.RealmBase.Digest(String, String, String). Then the code compiles ok, but I get this error when building with ant to make a war file: error: method Digest in class RealmBase cannot be applied to given types; [javac] encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,null); Should I not be writing code that needs classes from catalina.jar? Thanks, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, June 13, 2013 11:09 AM To: Tomcat Users List Subject: Re: Class cast exception when starting tomcat 7.0.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jane, On 6/13/13 12:38 PM, Jane Muse wrote: In the archives I thought the only unreleased versions would be specified beta. Please let me know if this is not the case. I'll admit it's not clear from the version number which versions are beta, released, etc. You have to look at the ChangeLog: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Each release contains a release date and (optionally) a comment on the quality of the build. The first non-beta version of Tomcat 7.0.x was 7.0.6. Tomcat 7.0.1 (distinct from 7.0.10) was actually not released probably because it was broken for some reason. When the Tomcat team rolls a release, there is a vote. If there aren't enough yes votes (or any no votes), the release is abandoned but the number isn't re-used. Anyhow, there's no reason to attempt to migrate from Tomcat 6.0.x to Tomcat 7.0.x by shooting for an early version of Tomcat 7.0.x: you should go for the latest. Also, if you mistype and say Tomcat 7.0.1 instead of Tomcat 7.0.10 or Tomcat 7.0.4 instead of Tomcat 7.0.40 (or Tomcat 7.0.41), don't get an offended when people tell you you are doing it wrong. Just say whoops, I meant 7.0.40 and move on. Back to your original problem... have you modified the Tomcat 7 installation in any way -- other than dropping your WAR file/exploded WAR into the webapps/ directory)? Also, do you have any Tomcat-related JAR files in your webapp's WEB-INF/lib directory? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRugqsAAoJEBzwKT+lPKRYkwcQALdDoGGk6ZNHg82Ow8vTjjrY dO/70UaIg69t4TsgIJApzd+ReSMbzrThby4Ok+EkYOEXLC1tZgbbQpTQdx0sjqXc k7fJl9oRQ/O9UP4lj+PR1iWL0zTX/Ze+eTQLIHiJ6rpNnyqgSOnZujsev1lbbaUZ A2w8GwiWOPvA17MIQUio1Rr/OKd6s7/02EKJQwbxIRoBh4jdaTalgJXCBKb5+60p EnNMautisYXQXrdE2hUhMgFX5EIyqPP4PZYxe2EKRRHlGuXnzybYJnuyxDLtGLY7 nTpOfy5LA5xuFLHEruHm7ARUo6Hb8AH2Qvi5saXDsp+6ddh6Fy4Id4JaWODk16Zl KbPQXk1QjZayw8/nmFkr2gWJc8pGYQMzmeCqSxiJ8FqcrXo/bTq4GJwFazqK4cvE xfQDLyCNXaNdbskJ3rM336173+j7spUhrVlS8LyZ7B7bRPPOzxt5CmOZ2b3Y5Ti+ uBTc1YUXQ74/gjoZCRet4xtaGwRfKXARVSebP6+33AtneOsAlbXejmz545ccmUWl T/9c31jchDw+JlpX04KPu5hJzAb+/Jk3HdVG6LGDrB4oKyxcJcmzvREDXzVt+L5q aPHhnAm8pAHYn1nSAR8k15NL61zDr16CC4ffzWu26c9DfSt9xq3XTg0ESPFv0U4J kxt8hkkwFdx5ZbXxnFgb =nulS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
I'm using the standard implementation of Realm. Here's the code
//Validate passwords
try {
if (oldTomcatPassword != null
!.equals(oldTomcatPassword.trim()))
{
TomcatConfig tconf = TomcatConfig.getInstance();
String digestAlg =
tconf.getTomcatPwdEncryptionType();
String encryptedOldPwd = oldTomcatPassword;
if (digestAlg != null)
encryptedOldPwd =
RealmBase.Digest(oldTomcatPassword, digestAlg);
if
(!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName))) {
errors.add(incorrectPwd, new
ActionError(error.password.incorrect));
}
}
As I said, it no longer compiles with catalina.jar from Tomcat 7.0.41. This is
not a surprise, that the signature would change, and I changed the code
accordingly. Now it is:
encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType);
Compiles fine now.
. However, when I build with ant, it says actual and formal argument lists
differ in length. I don't know why there's an actual and a formal argument
list. I swapped out catalina.jar.
188: error: method Digest in class RealmBase cannot be applied to given types;
[javac] encryptedOldPwd =
RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType );
[javac]^
[javac] required: String,String
[javac] found: String,String,String
[javac] reason: actual and formal argument lists differ in length
[javac] 2 errors
[javac] 1 warning
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Thursday, June 13, 2013 1:41 PM
To: Tomcat Users List
Subject: RE: Class cast exception when starting tomcat 7.0.1
From: Jane Muse [mailto:jm...@rocketsoftware.com]
Subject: RE: Class cast exception when starting tomcat 7.0.1
I had catalina.jar in WEB-INF/lib.
Very, very bad move.
It's needed because we have an implementation of Realm to store an
encrypted tomcat password users enter in the webapp.
Your custom implementation of Realm should be in Tomcat's lib directory, not
the webapp's. See:
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm?
Such a Realm should not be tied into the operation of any webapp, other than
configuring the webapp to use it.
If I remove it and add the catalina.jar from tomcat_home/lib to the
classpath
Not sure what you mean by adding it to the classpath; please explain.
I have to change the signature from
org.apache.catalina.realm.RealmBase.Digest(String, String) to
org.apache.catalina.realm.RealmBase.Digest(String, String, String).
That's because internal Tomcat APIs often change between levels. You certainly
cannot count on using an older version of Realm with a newer Tomcat (or vice
versa).
Should I not be writing code that needs classes from catalina.jar?
It would certainly be desirable not to be dependent on internal Tomcat classes.
Why do you think a Realm should be storing a password (encrypted or not)
anywhere? A Realm would normally be reading a password from some controlled
storage, not writing to it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
Thanks much. Problem was solved by removing an old catalina.jar for WEB-INF/lib. JMuse -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, June 11, 2013 7:38 PM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 From: Jane Muse [mailto:jm...@rocketsoftware.com] Subject: Class cast exception when starting tomcat 7.0.1 I'm getting a class cast exception when starting up tomcat 7.0.1 You can't be serious. That version was never released, and would be almost three years old if it had been. Use the current version: 7.0.41. Do a fresh download and clean install, verify that Tomcat is working, then add your webapps one by one, insuring that each one operates properly before trying the next. Do not directly copy any configuration from previous versions of Tomcat to the new one; modify the conf/*.xml files with whatever you need for your installation. Also make sure you do not have the same classes in tomcat's lib directory and the webapp's WEB-INF/lib or WEB-INF/classes directories. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Class cast exception when starting tomcat 7.0.1
I'm getting a class cast exception when starting up tomcat 7.0.1. I've migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly to 7.0.4. The error is: SEVERE: Begin event threw exception Throwable occurred: java.lang.ClassCastException: org.apache.catalina.deploy.SecurityConstraint incompatible with org.apache.catalina.deploy.SecurityConstraint at org.apache.catalina.startup.SetAuthConstraintRule.begin(WebRuleSet.java:745) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1282) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1543) at org.apache.catalina.startup.ContextConfig.parseWebXml(ContextConfig.java:1686) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1201) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:874) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:317) . . . Jun 11, 2013 2:17:07 PM org.apache.catalina.startup.ContextConfig parseWebXml SEVERE: Parse error in application web.xml file at jndi:/localhost/aldonsecurityservice/WEB-INF/web.xml Throwable occurred: java.lang.ClassCastException: org.apache.catalina.deploy.SecurityConstraint incompatible with org.apache.catalina.deploy.SecurityConstraint at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2687) at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2713) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1285) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) . . . . at java.lang.reflect.Method.invoke(Method.java:611) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431) Jun 11, 2013 2:17:07 PM org.apache.catalina.startup.ContextConfig parseWebXml SEVERE: Occurred at line 147 column 20 class load: java/util/LinkedHashMap$2 class load: java/util/LinkedHashMap$ValueIterator class load: org.apache.catalina.core.StandardWrapperFacade from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.util.InstanceSupport from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.InstanceListener from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: org.apache.catalina.core.StandardWrapperValve from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/catalina.jar class load: javax.servlet.descriptor.TaglibDescriptor from: file:/ALDON/ALDONLS/tomcat_alcsq/lib/servlet-api.jar Is it possible my XML parsers need updating. I'm still using the same ones in my WEB-INF/lib of the webapp: xalan.jar xerces.jar xerces-2.6.2.jar xml-apis.jar xmlrpc-1.2-b1.jar Thanks, JMuse
RE: Disable class monitoring for reloading container classes
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 out. But thanks for the info. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. And if autoDeploy=false then you have to shutdown tomcat, delete the CATALINA_BASE/WEBAPPS/APP_NAME directory, and restart tomcat in order for the webapp to deploy, correct? I think we'll do it this way in the production environment. you must remove the path attribute from the Context element: Ok, I removed it. It's not necessary because the name of the.xml file will be used as the context path, correct? we'd love to hear the resolution of the file timestamp changing when DST kicks-in I'll definitely let you know! 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, 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 WatchedResource as the context should not be reloadable if you set reloadable=true, though I haven't tried actually 'touch'ing web.xml just to see if it would trigger a context reload. We have a CATALINA_BASE/WEBAPPS/APP_NAME directory. Okay. If you have a standard server.xml, that means that APP_NAME will be deployed to /APP_NAME automatically, unless you have Host autoDeploy=false. We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf directory, the APP_NAME.war file, and an APP_NAME.xml file. Those files will be ignored unless there are other configuration settings that make them relevant. There is a context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml file with reloadable=false. This is the one I was changing. However it turns out that we used this one as a placeholder in case the one in the CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted. That sounds like a good plan. Again, the file you were editing was not being consulted by Tomcat. You'll need to copy that file into CATALINA_BASE/conf/[enginename]/[hostname]/[app_name].xml. As Chuck states, you must remove the path attribute from the Context element: it will be ignored at best and cause a double-deployment (or failed deployment) at worst. Or, it might cause your webapp to reload for unknown reasons :) We also have a context element in a place I hadn't seen before at: CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context element had reloadable=true. I changed it to reloadable=false and restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to all. This was going to be my final attempt: that you were editing the wrong configuration file. Still, we'd love to hear the resolution of the file timestamp changing when DST kicks-in. Please let us know what you find out. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3GZEACgkQ9CaO5/Lv0PBMWACeL/QV75reOUF3KPewOcdwp7KO jBEAoMGqeakQr/JsiEMpGFGJTwcSl7Nw =5BkZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
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.
Current GMT time (no DST): 2010-10-12 22:53:27 GMT
Current local time (with DST): 2010-10-12 15:53:28 PDT
File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
last modified timestamp: 1231267693000
the file was last modified 55656315 seconds ago
last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT
last modified as local time: 2009-01-06 10:48:13 PST
Change date to: 03/13/10
java com.aldon.lifetime.permissions.test.TimeChange
'/Aldon/Aldonls/tomcat20/lib/servlet-api.jar'
Current GMT time (no DST): 2010-03-13 23:55:24 GMT
Current local time (with DST): 2010-03-13 15:55:24 PST
File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar]
last modified timestamp: 1231271293000
the file was last modified 37253231 seconds ago
last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT
last modified as local time: 2009-01-06 11:48:13 PST
IBM has said they'll open a discussion with their development team and try to
get 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 for reloading container classes
-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
straightforward this way.
Now if you *really* insist, the modified version of the perl program,
below, will explicitly use a couple of C functions, themselves using
the builtin C structures to get the file's last modified time.
Running C in perl, scary stuff..
Are you submitting an application for an obfuscated C program, here?
Sheesh. What's wrong with a little C code?
Amazing: the C code is shorter than the Java code. *shrug*
Time.java (apologies for any re-formatting done by my emailer)
- -
import java.io.File;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.TimeZone;
public class Time
{
public static void main(String[] args)
throws Exception
{
if(args.length 1)
{
System.out.println(Usage: java Time filename);
System.exit(1);
}
// GMT current time
Calendar now = Calendar.getInstance(TimeZone.getTimeZone(GMT));
System.out.println(Current GMT time (no DST):
+ format(now));
// local current time
now = Calendar.getInstance(); // default = local
System.out.println(Current local time (with DST):
+ format(now));
// File timestamp
System.out.println(File [ + args[0] + ]);
File file = new File(args[0]);
long timestamp = file.lastModified();
System.out.println(last modified timestamp: + timestamp);
System.out.println(the file was last modified
+ ((System.currentTimeMillis() - timestamp) /
1000)
+ seconds ago);
Calendar tstamp = Calendar.getInstance(TimeZone.getTimeZone(GMT));
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as GMT time (no DST):
+ format(tstamp));
tstamp = Calendar.getInstance(); // default=local
tstamp.setTimeInMillis(file.lastModified());
System.out.println(last modified as local time:
+ format(tstamp));
}
public static String format(Calendar c)
{
SimpleDateFormat format = new SimpleDateFormat(-MM-dd HH:mm:ss z);
//format.setTimeZone(tz);
format.setTimeZone(c.getTimeZone());
return format.format(c.getTime());
}
}
time.c
- --
#include stdio.h
#include time.h
#include stdlib.h
#include sys/stat.h
int main(int argc, char *argv[]) {
time_t now;
struct tm *gmt;
struct tm *local;
struct stat *fileinfo;
int retval;
char *filename;
if(argc 2) {
printf(missing filename\n);
return 1;
}
filename = argv[1];
gmt = (struct tm*)malloc(sizeof(struct tm));
local = (struct tm*)malloc(sizeof(struct tm));
time(now);
gmtime_r(now, gmt);
localtime_r(now, local);
/* note:
RE: Disable class monitoring for reloading container classes
Chris, 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: Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. True, there is a bug in the IBM O/S where when DST hits, last modified date for a file gets interpreted as one hour difference. But if reloadable=false was working as it says it should, that would be a way to get around this bug. Can I safely say I've run into both an IBM and a tomcat bug? I'm on tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see anything for this issue that's been fixed. Thanks, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, October 12, 2010 11:16 AM To: Tomcat Users 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 it to deploy. No, Context reloadable=false (reloading is meaningless) means that Tomcat will ignore any files within a webapp that have been updated. Host autoDeploy=false means that Tomcat will not look for .war files and automatically deploy them. 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. Correct, if s/reloading/reloadable/. If that's what these mean, then we don't need them. Generally speaking, it's best to set both of these to false in production because you don't want anything to happen automatically. 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. Context reloadable=false ought to do the trick. But apparently tomcat is hard wired to reload if it thinks there's a change in that directory. Only if reloadable=true, which is NOT the default. 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-) Agreed, but it's hard to imagine how this situation would be detectable. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0pcQACgkQ9CaO5/Lv0PAmfwCfRHBsjuVKjBB6mGswfiZ4jHMk TvIAoL/EYf/iIcSsdM0u6eVYs4AwOLfI =mcCD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Here's my context.xml: Beginning of data** ?xml version='1.0' encoding='utf-8'? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- The contents of this file will be loaded for each web application -- Context !-- Default set of monitored resources -- !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- !-- Uncomment this to disable session persistence across Tomcat restarts -- !-- Manager pathname= / -- !-- Uncomment this to enable Comet connection tacking (provides events on session expiration as well as webapp lifecycle) -- !-- Valve className=org.apache.catalina.valves.CometConnectionManagerValve / -- /Context _ We are not defining our webapps context file in META-INF/context.xml. It is outside the CATALINA_BASE, in a separate directory that contains the War file, the context file and a conf directory for the webapp. Here's the contents of the webapp.xml file: Beginning of data** Context docBase=webapp_dir/webapp.war path=webapp reloadable=false /Context _ webapp is the name of the webapp directory in catalina_base/webapps/webapp. Jane End of Data -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, October 13, 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/lib, even though the docs say it does: Please log a bug. Note that bugs logged against old versions of Tomcat (6.0.18 is over two years old) are often met with upgrade to latest, then retest instructions. Upgrading would certainly be a good idea in general. Can I safely say I've run into both an IBM and a tomcat bug? I'm not convinced that either are true, honestly. There are plenty of explanations that do not require either your OS or Tomcat to have a bug. I'm on tomcat 6.0.18 and I've searched the 6.0.29 change logs, didn't see anything for this issue that's been fixed. We run in production on 5.5.x and 6.0.x both with default reloadable values (that is, false) and changes to files in WEB-INF/classes and WEB-INF/lib do not trigger automatic reloads. My experience leads me to believe that Tomcat works properly and that your configuration is somehow broken. Can you post your TOMCAT_HOME/conf/context.xml file as well as your webapp's META-INF/context.xml file? Take care to remove sensitive information, particularly from the latter. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+a8ACgkQ9CaO5/Lv0PAVswCfaSG12tBF+pILKASF6TKMQatf XvcAoL13iNq5KfXdTljWjAxg6TAl9Hns =k6mc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
Chuck, Thanks for your persistence! I'll try to explain with examples. 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. We have a CATALINA_BASE/WEBAPPS/APP_NAME directory. We also have a COMPANY_NAME/APP_CONF_DIR that contains a /conf directory, the APP_NAME.war file, and an APP_NAME.xml file. There is a context element defined in the COMPANY_NAME/APP_CONF/DIR/app_name.xml file with reloadable=false. This is the one I was changing. However it turns out that we used this one as a placeholder in case the one in the CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml got deleted. We also have a context element in a place I hadn't seen before at: CATALINA_BASE/conf/[enginename]/[hostname]/app_name.xml. This context element had reloadable=true. I changed it to reloadable=false 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 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 this: !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- We are not defining our webapps context file in META-INF/context.xml. It is outside the CATALINA_BASE, in a separate directory that contains the War file, the context file and a conf directory for the webapp. See below for your self-contradictory statement. Here's the contents of the webapp.xml file: Which is located where? Beginning of data** Context docBase=webapp_dir/webapp.war path=webapp reloadable=false /Context That's even more confusing and definitely not valid syntax, as well as having an illegal path attribute. webapp is the name of the webapp directory in catalina_base/webapps/webapp. So is your webapp in catalina_base/webapps or not? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
The IBM I uses its own integrated file system (IFS). You can access it locally with map network drives, but my tests did not involve doing that. Jane -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, October 13, 2010 3:20 PM To: Tomcat Users 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 filesystems. Usually the source and local systems are set to different 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- 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. Current GMT time (no DST): 2010-10-12 22:53:27 GMT Current local time (with DST): 2010-10-12 15:53:28 PDT File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231267693000 the file was last modified 55656315 seconds ago last modified as GMT time (no DST): 2009-01-06 18:48:13 GMT last modified as local time: 2009-01-06 10:48:13 PST Change date to: 03/13/10 java com.aldon.lifetime.permissions.test.TimeChange '/Aldon/Aldonls/tomcat20/lib/servlet-api.jar' Current GMT time (no DST): 2010-03-13 23:55:24 GMT Current local time (with DST): 2010-03-13 15:55:24 PST File [/Aldon/Aldonls/tomcat20/lib/servlet-api.jar] last modified timestamp: 1231271293000 the file was last modified 37253231 seconds ago last modified as GMT time (no DST): 2009-01-06 19:48:13 GMT last modified as local time: 2009-01-06 11:48:13 PST IBM has said they'll open a discussion with their development team and try to get a fix out. Someone had a suggestion about the use of NFS. Are you using a remote filesystem that might be mutating the file timestamps? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1+KIACgkQ9CaO5/Lv0PA0aQCffNfPI8JGlH9wrzRbzw9rFg9L DCgAnjKwE1Nodu6cj180aKqVfv5pvXBs =ki8t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
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: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 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: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- 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
RE: Disable class monitoring for reloading container classes
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. when running from the IBM I O/S. I'll talk to IBM next week and see if perl is supported. It might need to be a C program. It ran fine on Linux. If I run the equivalent in C and Java on the two machines and compare the difference, if they're the same then it must be tomcat. I will run them from the command line - before and after the time change. It'll have to be sometime next week. Mean Thanks, Jane -Original 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: 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 might be affected by the current DST setting when you /touch/ it, but not when you do a simple stat() call. My guess is that the problem is specific to the platform: either the JVM or the OS is adjusting the retrieved time stamp, making it relative to the current offset from UTC. Even though this particular OS is not widely used as a Java EE platform (compared to the number of Linux and Windows boxes out there), I'm a bit surprised the issue hasn't been reported elsewhere. Try using simple Java and C programs to check the File.lastModified() and stat() st_mtime values respectively, comparing the results both before and after the DST switch. That should determine if the problem is in the OS, the JVM, or Tomcat. Jane, Below is a simple perl program that will show the last modified time of a file, in 3 flavors : - the original timestamp as a binary value (number of non-leap seconds since the epoch, on most systems this is 00:00:00 UTC, January 1, 1970). - the same timestamp as GMT date/time (this is Greenwich time, non DST-adjusted) - the same time stamp as local time (DST-adjusted) Copy and paste this into a text file, save it as showmodified.pl, then type perl showmodified.pl file_path What would be interesting would be to run the program on your two different servers, to see if they answer differently. This does not use the Java JVM in any way. It uses perl, which itself uses mostly the built-in C library of the OS. So it will tell you what the OS responds for the file timestamps. Someone here might be able to provide a quick Java equivalent, to see if the JVM thinks differently on the same system. Note : I also send the program as an attachment. The list will probably strip it, so I emailed a copy to you directly. #!/usr/bin/perl # showmodified.pl use warnings; use strict; my ($sec,$min,$hour,$mday,$mon,$year); my $subject = $ARGV[0] or die missing argument; die File not found or not readable : $! unless ((-f $subject) (-r $subject)); my $now = time(); ($sec,$min,$hour,$mday,$mon,$year) = gmtime($now); $year +=1900; $mon +=1; print Current GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($now); $year +=1900; $mon +=1; print Current local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; print File [$subject]:\n; my ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks) = stat($subject); print last modified timestamp : $mtime\n; print the file was last modified ,$now-$mtime, seconds ago\n; ($sec,$min,$hour,$mday,$mon,$year) = gmtime($mtime); $year +=1900; $mon +=1; print last modified as GMT time (no DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; ($sec,$min,$hour,$mday,$mon,$year) = localtime($mtime); $year +=1900; $mon +=1; print last modified as local time (with DST) : ,sprintf(%04d/%02d/%02d-%02d:%02d:%02d,$year,$mon,$mday,$hour,$min,$sec),\n; exit; - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
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. I have reloading=false and autoDeploy=false set in the context.xml and server.xml. 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)? 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 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 DST-clock-setback. For instance, if the clock goes from 02:00 early Sunday morning to 00:00 early Sunday morning, then you should only experience some kind of confusion if you deploy between 00:00 and 02:00 the first time through early on Sunday morning. +1 actually. Logical. I browsed the code and it looks like the reload-check is done in the WebappClassLoader.modified() method which you can find in here for Jane's specific version: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/java/o rg/apache/catalina/loader/WebappClassLoader.java 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 timestamp is still in the past. In either case, this seems weird. 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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvM54ACgkQ9CaO5/Lv0PA6rACfUghfrik2nmW9n7usJZhUMKbZ W9UAnA82HPzCB8rcJTsi8hpou7kzeu/Z =kvUe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: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- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
There are several Java's on the IBM machine. Yesterday I performed tests by changing JAVA_HOME in the catalina startup script to Sun's Java 1.5 and Sun's java 1.6. Previously it was IBM's J9 1.5.0. The results were the same with the various JVM's. 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 loader. When the application is shut down by tomcat, the native library does not get unloaded from the class loader. This only happens when the JVM is brought down. Thus when the application starts up after tomcat reloads it, we get an UnsatisfiedLinkError. http://java.sun.com/docs/books/jni/html/design.html Thanks. -Jane -Original Message- From: 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, 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 the other. The version where it does not work is Java 1.5.0, and where it does is Java 1.6.0. I have a question into IBM to see if I can change the Java used by the O/S. I believe that if you phrased the question like that, they may not understand what you mean, as the OS itself probably does not use Java. Do you know how I could change the JVM used by tomcat on a machine? To change the JVM used by Tomcat is easy, but first you need to install a 1.6 JVM on that machine. You should be able to install the JVM 1.6 in addition to the existing 1.5, if you have any concern about the possibility of breaking other applications. For the exact way to do that, you will need help from an OS specialist for that machine. Once you have installed this 1.6 JVM, having Tomcat use it instead of the 1.5 JVM is easy. Basically, it consists of setting the environment value JAVA_HOME to point to the new JVM before starting Tomcat. That's all there is to it. That needs to be done somewhere in the scripts which are used at Tomcat start, but I cannot tell you where exactly on that platform. If Java and Tomcat are IBM packages on that platform, then you will probably also need an OS specialist to help you with that. re: your fourth point I test this by changing the system time on the O/S. Right. But my point was : since in reality, on a productive system, this is happening only twice a year, does it matter if those times the application(s) get reloaded ? (In fact, I strongly suspect that it may happen only /at most/ once a year, and then only in very specific circumstances. It is your changing of the system time which triggers the reloading, but it would probably never happen in reality on a production system). I couldn't figure out how to test your last guess because the context element in tomcat's context.xml wouldn't accept the reloadable attribute. That was only a wild unsubstantiated guess. I expect someone else more qualified to shoot down that suggestion, just about... now. Thanks, Welcome. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
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 changed in March 2007 for
USA time zone.
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 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 6.0.18 on an IBM i (OS400) version V6R1. When daylight
savings time hits, our application gets reloaded, and the following
statements are in catalina.out:
Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext
reload
INFO: Reloading this Context has started
Does this happen with every DST change that results in the clock being
set backward? I haven't looked at the code, but I can't imagine that
the BackgroundProcessor keeps the timestamp of the last file scan
around for comparison. Instead, I would expect logic similar to this:
while(true) {
sleep
find files modified since last context startup
if file list is non-empty, reload context }
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 DST-clock-setback. For instance, if the clock
goes from 02:00 early Sunday morning to 00:00 early Sunday morning,
then you should only experience some kind of confusion if you deploy
between 00:00 and 02:00 the first time through early on Sunday
morning.
+1 actually. Logical.
p
I've never observed a DST clock-setback trigger a webapp reload.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Disable class monitoring for reloading container classes
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? Thanks, Jane -Original Message- 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 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 6.0.18 on an IBM i (OS400) version V6R1. When daylight savings time hits, our application gets reloaded, and the following statements are in catalina.out: How about fixing the system time zone to be one that doesn't change with daylight time savings? p Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started We have been able to stop the application from reloading on a different version of the IBM i, version V7R1, by using reloadable=false. However on the V6R1 O/S the application still reloads because the background processor detects a timestamp change when DST occurs. From the documentation, it doesn't look like backgroundProcessorDelay can be used to suppress backgroundProcess, just to delay it as its name implies. We would gladly upgrade tomcat to a more recent version if we thought this issue had been resolved, but I don't see any mention of it in the change logs. - Jane - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Disable class monitoring for reloading container classes
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 6.0.18 on an IBM i (OS400) version V6R1. When daylight savings time hits, our application gets reloaded, and the following statements are in catalina.out: Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started We have been able to stop the application from reloading on a different version of the IBM i, version V7R1, by using reloadable=false. However on the V6R1 O/S the application still reloads because the background processor detects a timestamp change when DST occurs. From the documentation, it doesn't look like backgroundProcessorDelay can be used to suppress backgroundProcess, just to delay it as its name implies. We would gladly upgrade tomcat to a more recent version if we thought this issue had been resolved, but I don't see any mention of it in the change logs. - Jane
RE: Disable class monitoring for reloading container classes
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 the other. The version where it does not work is Java 1.5.0, and where it does is Java 1.6.0. I have a question into IBM to see if I can change the Java used by the O/S. Do you know how I could change the JVM used by tomcat on a machine? re: your fourth point I test this by changing the system time on the O/S. I couldn't figure out how to test your last guess because the context element in tomcat's context.xml wouldn't accept the reloadable attribute. Thanks, Jane -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, October 06, 2010 1:34 PM To: Tomcat Users List 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 reloading for the context with reloadable=false? I'm using tomcat 6.0.18 on an IBM i (OS400) version V6R1. When daylight savings time hits, our application gets reloaded, and the following statements are in catalina.out: Mar 14, 2010 3:00:08 AM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started We have been able to stop the application from reloading on a different version of the IBM i, version V7R1, by using reloadable=false. However on the V6R1 O/S the application still reloads because the background processor detects a timestamp change when DST occurs. From the documentation, it doesn't look like backgroundProcessorDelay can be used to suppress backgroundProcess, just to delay it as its name implies. We would gladly upgrade tomcat to a more recent version if we thought this issue had been resolved, but I don't see any mention of it in the change logs. - Jane Hi. I don't really know the answer to your questions, but I will hazard a couple of guesses based on the documentation, and on your above description. First, if I go by the description in the documentation, for the reloadable attribute of the Context element : Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand. It thus seems that the default value of this attribute /is/ false. So your setting it to false explicitly should not change anything. Or, the documentation is wrong.. Second, are you sure that you should not be using the autoDeploy (=false) attribute of the Host element instead ? According to its description, this seems more closely related to the kind of issue you mention. Third, according to your message above, you seem to be using the same Tomcat version on two systems, but they have a different OS. Presumably, whatever it is in Tomcat which checks if it is time to reload an application must be comparing timestamps, uses the same call to the JVM for ditto, and the JVM (if it is the same), probably uses the same call to the underlying OS. So the different behaviour seems to be JVM or OS-linked, not Tomcat-linked. Do you have any idea why these two OS'es or JVM's return a different reponse to Tomcat for the same call ? (Maybe the difference in OS is just incidental, and it is really a difference in the setup of these systems which makes the difference; or maybe it is the JVM which is the cause. Are they the same ?). Fourth, you are talking about a change resulting from a DST adjustment. Isn't this something which happens at most twice a year ? Even if it does reload an application then, is this really a problem ? (I'll admit again that I don't know, and I'm just curious). And also, supposing that you get an answer here, does that mean that you will have to wait 6 months to see if it works ? And last (but here I'm really really guessing), the INFO message you mentioned seems to talk about a StandardContext. Maybe this is the one which is described by the context.xml file in the main Tomcat configuration directory (or at least as a default for all contexts). So, supposing that this attribute really has an impact, have you tried to add the reloadable=false there ? (no guarantee that this will not have other consequences however
