tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: Tomcat 7.0.23 won't start
Date Fri, 09 Dec 2011 14:24:11 GMT
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.


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.


> 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?



> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



View raw message