Thanks for the continuing info... I've been working with the java servlet stuff since early 2000. But knowing how to make it work vs. knowing the 'correct, intended' design philosophy have often been two different things. I know it'll be better in the long run learning the correct philosophy. Just painful considering how much code I've developed in 14 years that is probably not the 'right way'. But I'm in it for the long haul... So pressing on....
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. 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.... Am I on the right track? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
