tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Proposal: use tomcat-version-number in server.xml <Server> element?
Date Fri, 02 Dec 2011 15:57:44 GMT

This may be a waste of time, but it's worth suggesting IMO.

We have lots of users who try to upgrade between major versions of
Tomcat by simply installing the new Tomcat somewhere, copying their
configuration over (primarily server.xml), dumping their webapps into
webapps/, starting the server, and then running to the users' list when
it doesn't work.

I was thinking that we could add a "version" attribute to server.xml's
<Server> element that could allow Tomcat to bomb on startup if the
version wasn't correct/compatible.

Such a version string could be as simple as "5.5" or "6.0" or whatever.
It could also track the actual release version "6.0.32", or even be
something more opaque like Java's class file version numbering.

A server reading an incompatible configuration file (almost always a
newer version of Tomcat reading an ancient version of the file) could
complain with an error message a reference to the documentation about
how to properly upgrade Tomcat.

Does anything think:

1) This would actually help people? You get a nice error message instead
   of ClassNotFoundExceptions and warnings about unrecognized property
   names and stuff.

2) This would be a total PITA because you have to go find the magic
   version string for your new Tomcat version? The intent would be
   to have the version string /already/ in the server.xml that ships
   with Tomcat.

3) This could help us when we have to introduce some semi-breaking
   change to server.xml without a major release bump. In these cases,
   the warning could be something like "There are incompatibilities
   between your version of server.xml and this version of Tomcat: please
   see [url-to-incompatible-property-docs] for more info" instead of
   "go see the upgrade documentation".

This kind of thing is probably too late for TC 7, but TC 8 could
implement it pretty trivially.


View raw message