I've got the same problem with session retention after a reload(if contexts' reloadable="true" that is) - and it sounds like it will still be a problem after I upgrade my development practices and start using WARs. Since you seem like a free thinker :) do you have any ideas on a solution for that problem? I was researching load-balancing Monday and came across a solution that mentioned sessions were retained on a different instance of tomcat(but were accessible to all, somehow - too much for me to digest); perhaps that will provide a path? Here's the link: http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html
Regards, JW
Robert Bateman wrote:
On Mon, 2004-10-11 at 18:27, Jonathan Wilson wrote:
Bob,
You just answered my follow up to your previous email :)
Hmm, so I run a concurrent version of my production app(being careful not to impact the databases) either on a different instance of Tomcat or just a different context within the same instance of Tomcat.
Yes. I use a tool called ANT to process, build and deploy my applications via WAR files. In my ANT build file, I have separate tasks that deploy to production and test. Because I am deploying using a WAR file, each application has it's own configuration file (server.xml) called context.xml. In my case, I have two different configuration files - each specifically tailored to the environment I will deploy into. All my ANT task does is copy the appropriate config during the build.
Then when I'm ready I package up the source code into a WAR(what tool do I use for that? - must do research), copy it into the production servers
You build the WAR file with a program called JAR. WAR files are zip files with different extensions (in fact, you can rename a WAR file to .ZIP and open the file for inspection.)
As you build the WAR file, you want to compile any source modules that need compiling and place them into WEB-INF/classes. JAR files go into WEB-INF/lib so that the WAR file is self contained.
webapps directory(and hopefully have all the configuration set properly
If your version of Tomcat supports it, instead of copying into the WEBAPPS folder, you can use the manager applets' UNDEPLOY/DEPLOY capability. This allows the server to take your WAR file and put it into the appropriate place on the server. Under TC 4.1 and newer, I've been using a task in ANT that communicated with the manager applet for me and does all of the un/deploying - quite spiffy.
to auto-expand) and then what? If the WAR is automatically expanded do the new files take effect immediately
I'm not sure about TC version 3 (I use 4.1 and 5.0), but on my server, the WAR file is placed into the appropriate place and put "live" as soon as it's deployed. I've found in my environment, that I have to be careful not to deploy when there are active sessions because my application doesn't handle the refresh gracefully.
or do I need to restart tomcat still. Does the context in the server.xml need reloadable="true" set for a WAR file expansion to take effect immediately?
With WAR files, you don't touch server.xml any more. All of your web application specific configuration parameters are placed into context.xml in a folder called META-INF within the WAR. The server parses this file to determine how to deploy your application, what resources it needs, logging, etc. Nicely self contained.
Thanks for the info..connected some dots for me.
New Question (While I've got ya :): Given that I can use a WAR file to "deploy," would you advise using Tomcat 5.x as my test server, creating a WAR and then deploying that to a production 3.3.1 server?
I gotta agree with QM on this one... Test with the version that is in production.
Is it possible for you folks to atleast migrate up to TC 4.1.xx in production? Your closer to current that way and migrating to 5.xx might be easier once you feel comfortable with TC 5.
This would kinda let me test using 5.x and still support a 3.3.1 box. The app is very self-contained, except for a load of jar's in the lib.
Thanks for you time!! JW
Bob
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
