tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Overberg <>
Subject Re: How to deploy when JSPs need to change regularly?
Date Thu, 03 Nov 2005 16:53:17 GMT

Thanks for the reply!  Regarding your idea of using rsync- does that 
still involve building a .war file?  I'm pretty ignorant of how 'real 
sites' do this, and of the whole deploy mechanism in general.  I mean, 
how do people manage 100's of tomcats?  I'm trying to get my system to 
the point where I can just deploy a new tomcat node to a new server 
without much hassle, and manage from a central console.  I have thought 
about using rsync, but I guess the thought of running things from a file 
structure (and not a war) just feels...I dunno... 'amatuerish'.  Maybe 
I'm just paranoid.

My shell-fu is much better than my java-fu, so I can figure it out that 
way, I guess I just assumed there's some big, complex apache project for 
managing large numbers of tomcats remotely.

Thanks again!


Richard Mixon wrote:
> Kurt,
> Just using a ".war" file to deploy from should not keep you from updating
> the JSP pages. We do occasional patches to our JSP pages in a two-server
> cluster with no problem.
> However if you pre-compile the JSP pages before building the ".war" file
> that could pose an issue.
> Using CVS as a replication utility to install modified JSP's to each
> Tomcat's webapp directory is pretty innovative - but I wonder if it does not
> also present some problems. For one, I've never seen a WAR file build that
> has the entire CVS "checkout" directory structure in it - i.e. the hardcoded
> "CVS" subdirectory and its associated files that are placed in each
> directory of the checked-out CVS module. That does not mean it will not
> work, it probably should. In fact if you are going to do updates from CVS
> you would need to be sure those CVS directories were in the ".war" file.
> It might be a good idea to use an rsync (on Linux/Unix ?) script or
> something similar instead of CVS to replicate the updates. 
> Hope this helps - Richard
> -----Original Message-----
> From: Kurt Overberg [] 
> Sent: Thursday, November 03, 2005 7:20 AM
> To:
> Subject: How to deploy when JSPs need to change regularly?
> Hello All, I'm currently running mid-sized website (load balanced across
> five servers).  Its a fairly large web application with a front and a
> back-end.  In production, the application is sitting exploded in a directory
> which tomcats point at.  It looks rather like a development sandbox.  I do
> this because our web people need to modify the content
> (JSPs) of the website on a fairly regular basis.  Right now, they can just
> "cvs update" the webapp directory and things work great.
> However, this is a bit of a deployment nightmare.  Everytime I need to push
> out a new version of the core servlets, I have to manually update each and
> every sandbox on each server.  I would MUCH rather use a .war file to deploy
> to each server and let tomcat deal with things (since the website is really
> starting to grow).  Is there any way to deploy a .war file and then let
> people modify the JSPs in it?  Complicating things is that we use CVS for
> everything, and new JSPs make their way to the site via a cvs update.
> Right now, it seems like everytime someone changed a JSP, I'd have to
> re-deploy the entire thing, when really its just a few JSPs that have
> changed.  The web guys update the site an average of 10-20 times per day.
> Any suggestions?  Seems like this would be a pretty common problem, but I've
> found nothing on google, et al.  Do I have to move to some sort of content
> management system, where the servlets and JSPs remain static and the data
> comes from a DB?
> Thanks for any help or suggestions!
> /kurt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message