On 08/12/2011 18:42, Christopher Schultz wrote: > Jacob, > > On 12/8/11 10:04 AM, Jacob Champlin wrote: >> Practical: This was my sandbox config file. I switch between 6 >> different applications. I do this by switching server.xml files >> when I switch projects. This keeps things minimal (not starting up >> 6 connection pools), its easier to switch one file, and it makes >> restarts faster. > > You could do this in other ways. One way I like to do this is with > different CATALINA_BASE structures. This makes upgrading easier (for > me), too. Another way is to move deployment descriptors in-to or > out-of the conf/Catalina/localhost directory. Likewise, you could > choose to include (or not) foo.war in the webapps/ auto-deployment > directory.
+1 Splitting _HOME & _BASE is clean. >> Opinion: I hate over-decomposition and I preferred the days when >> tomcat was only configured with server.xml. > > Fair enough. I don't think it's a case of over-decomposition, personally. >> Tomcat's configuration is not that complicated, do we really need >> a bunch of configuration [files?] There are already a bunch of configuration files. > Modifying server.xml requires a Tomcat restart to re-read the config > file. The other methods offer greater flexibility and are, IMHO, > easier to do, anyway. Also, it's tougher to disable a Tomcat instance > with a broken META-INF/context.xml than it is to disable one with a > broken server.xml. > >> Its bad when one thing becomes two, and hence good when two things >> become one. That's far to general a statement to hold water IMO. > I'd argue a negative premise on that one. Dying is bad, but un-dying > is *way* worse. ... mmmm .... brains ..... > >> bet your also in the micro kernel camp. > > Flame bait ignored. LMAO That's a hell of a judgement considering I only asked a simple question. >> I know lots of people clamored for being able to configure the >> connection pool in there war file. I'm not really sure I know of any evidence to that effect. There's nothing to stop people programmatically configuring their DB pool in their app - and in fact that's what many people using Hibernate are actually doing. > I'm not sure that would have been a good idea, as it's generally a > service offered by "the system" and not configured by the webapp. > Maybe you meant the TC deployment descriptor (context.xml) which can > be totally controlled by the sys admin and need not be in the WAR file > itself. > >> I don't know why anyone would do this, our WAR file runs in any >> environment where the jndi name is present. See above. > Yes, that's the point. You're using Recommended Technique(TM). > >> They have to build separate WAR files for each environment. Nope. > Just because it's Recommended Technique doesn't mean that it's best > and/or appropriate for your (or anyone's) environment. There are > always some good (and usually lots of bad) reasons to deviate from that. > >> Basically I think the context.xml is stupid. If it matters so >> much change the document definition. > > Sounds like your webapp doesn't need a context.xml. How's that for > simplicity and ease of configuration? +1 p > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
