tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Proposal: use tomcat-version-number in server.xml <Server> element?
Date Fri, 02 Dec 2011 18:05:36 GMT
On 2 December 2011 17:35, Christopher Schultz
<> wrote:
> Filip,
> On 12/2/11 12:26 PM, Filip Hanik - Dev Lists wrote:
>> Chris, this would be your [cue] to rethink the solution one step further
>> down the line.
>> Not too long ago, I add in a property validator. Tomcat used to silently
>> ignored invalid attributes, so misspellings such as
>> <Server sport="-1" shutdowns="SHUTDOWN">
>> This used to run with default values, with zero logging. This has been
>> addressed for the most part.
>> but there are still [loopholes], particularly with values and elements
> Definitely. I'll see if I can take a look at the validator to see how it
> might be extended to look for certain things.
> I just cringe whenever I see someone who has a <Logger> element in their
> server.xml or "debug" attributes all over their elements. The former may
> require a different strategy, but the latter should already be handled
> by your validator (which really sounds like a complainer :)
> Tomcat already uses commons-digester to read its configuration files, so
> it should be trivial to add some rules to look for specific, definitely
> BAD things (like <Logger> anywhere, for instance).
> IIRC, Tomcat has hard-coded digester rules for just about everything.
> Does anyone know if that was an intentional design decision or just what
> happened at the time? Digester may have more elegant ways of doing the
> same things these days (like XML configuration)... and that would make
> it easier for me to add something like this: just a one-liner in the
> configuration for each known-bad element/property instead of modifying
> the code.

What about implementing something like Java does for deprecated code?

That is, if the checking algorithm notices anything odd in the
configuration, log a _single_ message to say the config looks wrong.
The message should say how to generate more verbose logging (and
possibly stricter checking), e.g. via a System property or marker
file, or even via a command-line option. [Asking them to edit the xml
file would likely be counter-productive...!]

If it was found that even basic checking caused a slowdown in startup,
then just log a message saying how to run the checks.


May I suggest that any warning messages generated by the checking
algorithm have a unique code for each error type; if it is reasonably
short (cf. Http's 404 etc. or VMS's RMS-FNF) it might make debugging
on the user list easier.

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

View raw message