-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jerry,
On 1/31/14, 10:16 AM, Jerry Malcolm wrote: > I think my biggest philosophy change is the WAR scope. I've > always been under the impression that a WAR file was totally > generic and had no site-unique data. In other words, you bought a > WAR 'off the shelf', put it on a server and then 'wired it in' as > necessary to make it work on a particular host site. If you needed > to use the same app on 5 sites, you copied the same WAR to 5 hosts > and wired each one in uniquely for that host. Obviously the unique > wiring is only required if there are unique differences per host. > But I have db requirements. So that puts most of my apps in that > category. For the most part, you are right: just copy the WAR file 5 times, etc. You can always modify the META-INF/context.xml file to make changes like database connection info, etc. If that doesn't work for you, you can go with the conf/[engine]/[host]/[webapp].xml route: that file will always override whatever is in the WAR file (or exploded WAR directory). This gives ops staff the power to configure things *without* doing brain-surgery on the WAR file. > What I think I hear you saying is that this is not the right > philosophy (which is fine with me once I understand it...). So > really, the better approach is to build 5 different WAR files with > different META-INF context files. If the build process can > support it, actually put the unique resource tag with the > site-specific db parameters in the META-INF context file. So I > build a site1\app1.war, site2\app1.war, site3\app1.war. Not a bad > approach if that's recommended. Some work on my build process. > But definitely doable. Just requires me to shift my head around a > bit.... What you have described above is how we do our build process, here: we choose a configuration bundle and build a WAR from that. But you can just as easily build a generic WAR and then to what I've described above. It's all about what makes the most sense for your environment. The good news is that, it's not terribly difficult to switch from one to the other. Changing your build process might be difficult. Changing the deployment process is usually easy. One more suggestion: script everything. That way, you are essentially self-documenting your procedures. Write lots of notes to yourself in the build/deployment scripts to remember what you were thinking at the time. They may help you later when you go back and say "what was I thinking?" I like to use Apache ant and most build-related operations, but bash, Perl, Python, Ruby, etc. are all perfectly reasonable scripting languages to use for this kind of thing. Just use whatever tool is best for you and your team, but definitely do it. If it's all in your head, you'll forget some step at some point and not realize it. Or you'll get hit by a bus and nobody will ever be able to re-build the server in the way you did it. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS68AEAAoJEBzwKT+lPKRYmKgP/1+VY2e2icAMqCHpsqo5wWeE DXkiuYGhipmoAMb49VUYDjfx4VKx2m+N0AiU8MHGA474m4dpXZaTUZKJMJoebAg1 m8hUFkCIDxSZ6FeSgY2OX3j60tu0b/O5ocgERhC/XRYIJnc54ucmbDPt30zrBv+n kIIFM8yut+2/rHtdD/47YMV4Kch/669mXoDRTdennQk/TJTM7zhBdylAYQ6a3f4R OAPqi8JAR0DAf05REJD4jqADvTDlyYqJWnsj2ICWvXXfaZ2I1C1f4BV2DcPJkWsk /t8PrXvEoQLdCDCXwcKdcIsIFK16mwCmtfD/lMcyke9bQU4nXl8FwXabTjqIJtdH btj3P0PV+EJcyt8vvaZ2VW/YKV0nRU73CBFuho/nInvFExEg5qw9zuXEGZ8JrVcW ZmKNI/lHPQp5P/cKyYJGT1K4WHwinSJP0dD4zXfgXxzM75w/k/RY0y36jj7HhkOu zlALUOHpKqe0P10Xc1tK+Vl+l5GiBReP8vOznfTZ+keCg5ph2gfhWeyHiyL7gpwq t+NRsDgZMAqB+J87t2ARzlbdeyQUVnaIjCaAf+0iDmtYNHWBHuEAr4IyHTiZavut foNHNQvzFnVlJVo/PbbKOw1WdUliCLzGkXjv/xle0qCHt8SO0eqAe+iVqCTCZ/pG Eez4QJ1Y/N5ycfYQzDrs =jaN8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
