Hi Steven,
We run 5 Tomcat servers (still on 4.1.x so not clustered) and use CVS with two tags: 'stage' and 'prod'. When a push script is executed the server pulls the appropriate version from cvs and then performs an ant task to deploy the app, compiling any changed classes. We find that this works just fine and haven't really had any issues.
Check that you are using <jsp:include ...> (include on execute) rather than <@ include ...> (include on compile) as this *may* be causing the issue.
Just out of curiousity why are you are deploying individual apps if they are so similar? Why don't you just implement a "branding" infrastructure and run a single app with multiple brandings?
Just a thought ...
PJ
Steven J. Owens wrote:
Hi folks,
I'm interested in hearing how people are dealing with configuration management issues.
We've been running into some problems with JSP recompiles, particularly when the changed JSP is an included JSP. Tomcat seems to sort of get stuck on the old version, even if we restart tomcat it doesn't reload. Manually deleting the foo_jsp.java and foo_jsp.class files from the tomcat/working/etc directory and *then* restarting seems to do the trick.
Somebody I talked to suggested that using a WAR file and
redeploying would make tomcat more reliably recompile the JSPs.
I've been meaning to move to using WAR files sooner or later, but
one question has always bugged me - how do you save your
deployment-specific configuration info?
If I understand correctly, WAR file is just a glorified JAR file, which in turn is just a glorified tar file. So unless you're unjarring it, editing the config file and rejarring it, you can't really muck with the config settings inside it. How/where do people normally keep the configuration variables for the webapp?
We have a single tomcat installation with a dozen almost-identical webapps, one webapp for each customer. When we do our jobs right, each app is in fact identical, except for:
- two colors in the app-wide CSS stylesheet - the customer's logo image - the <CONTEXT> tags in server.xml - a few details of the web.xml file (webapp name, database resource name) - a properties file with a couple dozen configuration properties - a separate database in the mysql server
We extend and refine the application constantly, so we're changing the code every month or two. So far we've been using cvs to manage this. Each webapp is a cvs checkout ; the specific files mentioned above exist in template form in the checkout (e.g. web_template.xml, styles_template.css) that we copy into the right name for deployment and then edit, so they don't get overwritten by cvs.
Using cvs worked pretty well for a while, but it's gotten unwieldly, especially when we run into the JSP recompiling problem, because then we have to restart the entire server to try to get it to recompile the jsp.
This reminds me of another question; I'm beginning to wonder if we wouldn't be wiser to use a dozen separate tomcat installations. I know that in theory using the same tomcat installation for multiple webapps is supposed to be "standard", but any time we have to tweak the server.xml-level configuration of a single webapp, we have to restart all of them. How do people normally deal with this? Is it at all common to run multiple tomcat servers behind apache for this sort of purpose?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
