On 2 December 2011 17:35, Christopher Schultz <ch...@christopherschultz.net> 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
