> -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Thursday, February 16, 2012 3:32 PM > To: Tomcat Users List > Subject: Re: generic deployment question > > Jeffrey Janner wrote: > > Assume latest Tomcat 6.x for current deployment, and 7.x for future > deployments. > > > > I host an app for a couple of dozen customers. Naturally, upgrade > time can be a bit of a pain, > > why ? > > and I'd like to simplify things. > > Assuming that all the customer-specific information (DB connection > info, logger info, etc.) can be described as resources in the > context.xml file, would it be possible to put the actual webapp in a > single pre-exploded directory without causing Tomcat fits? > > > > It seems to me that there is a logical problem : if you have only 1 > webapp, then you also > only have one context.xml. So how are you going to specify per- > customer specific > configurations ? > And even if you do, how will you distinguish a request from one > customer from a request > from another customer, and use this information to select the > appropriate resource > definition ? > > Personally, I tend to think that you are going to trade an small > inconvenient (having to > update 24 war files), against a vast complication of your application > and setup. > And lose a lot of flexibility too, like if ever one customer wanted > this thing just a > little differently.. > > I am told that there are tools to automate such a multiple deployment, > so that you would > only have to give a command once, and it would deploy the same > application to 24 locations. > > That was just my 0.02€.
Sorry André. Realized after I posted that I'd left some details out. Each customer is their own <Host>, with their own DB and a few other resources. It's not really one web-app, but a single set of code deployed multiple times. From the developer's standpoint, they are developing one product, but I need to deploy it as many times as the sales guys sell it. As far as the current deployment method being cumbersome, that's primarily a result of decisions made years ago by a developer who was kept in a bubble in a closet who was provided food through a slot, i.e. really had no idea of real-world deployment issues. As it is, I don't even use war files, as that would require me to build a specific one for each individual customer, because of some of those years-old decisions. I'm trying to get the current team to make adjustment so that war files, or the way above, would be feasible. Btw: we don't customize things for individual customers in that manner. All custom requests are integrated into product, and if not useful for everyone, we control access via settings outside of code. And I could automate deployment of war files with a Windows bat script that does a couple dozen copy commands and maintain that. Don't wanna. But, really, I just wanted to know if my original suggestion would cause issues with Tomcat. Essentially, I don't see why I should zip up an app directory structure into a war file, just so Tomcat can unzip it a couple of dozen times. __________________________________________________________________________ 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.
