On 08/12/2011 18:42, Christopher Schultz wrote:
> Jacob,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>> 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.
>=20
> 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).
>=20
>> 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=
=2E
>=20
>> 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
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>=20
--=20
[key:62590808]
|