2011/12/2 Filip Hanik - Dev Lists <devli...@hanik.com>: > On 12/2/2011 10:11 AM, Konstantin Kolinko wrote: >> >> 2011/12/2 Christopher Schultz<ch...@christopherschultz.net>: >>> >>> All, >>> >>> 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. >>> >> -1 >> >> 1. I strongly dislike relying on any numbers in such a feature. As >> people say, you should not rely on numbers, but on the features that >> are available. > > I have the exact opposite reaction. It seems like a strong -1 here is an > engineering preference, specifically from one that already knows the product > inside and out. > However, I run into this very often, with Apache Tomcat and other products. > Where ease of use is hindered by the product having almost zero validation > of it's own configuration. > > It's very different making a -1 statement from behind a developer IDE, but > try to sit next to a customer with 3000 tomcat instances running and tell > that administrator why Tomcat is not telling him his config is wrong, cause > the config changed between 5.0 and 5.5 >
I am OK if the feature does not rely on numbers. > >> >> 2. It is social problem. You cannot teach people with this feature. >> People will always be smarter than your tool. > > Opposite again, ease of use comes from the tool. advanced usage comes from > the people. > > >> >> I'd suspect that the first thing that most people faced with such >> problem will do is to edit the number. They wouldn't read the docs. > > so then there is room for a different solution, but yet attacking the same > problem. > > >> >> 3. It does not prevent someone from Googling ancient articles and >> copying parts of config from there. > > It does not solve it, but it refers to the very problem to address, and > actuates that it is a problem. > So it seems like, the problem is obvious, the solution may not be enough. > > Chris, this would be your queue 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 loop wholes, particularly with values and elements > What we have now: 1. "catalina configtest" command in TC7 2. org.apache.catalina.startup.EXIT_ON_INIT_FAILURE system property in TC 6 and 7. 3. The rule created by digester.addSetProperties(name). Those are org.apache.tomcat.util.digester SetPropertiesRule.java SetPropertyRule.java that log a warning if IntrospectionUtils.setProperty() returned false. IIRC that is our own change wrt. Commons Digester. It is in TC6+. What we do not have: 4. The digester rules just print a warning, but do not cause a fatal failure. 5. There is no handling of unexpected XML elements. 6. IntrospectionUtils.setProperty() just returns a boolean. It hides the actual error that occurred during property assignment unless you enable its debug logging. I think 1) It might be good to have EXIT_ON_INIT_FAILURE=true by default in TC8. I already use it on all my configurations. 2) Maybe improve "configtest" command. I do not have experience using it though. I wonder about the following improvements to it: a) operate as if EXIT_ON_INIT_FAILURE were true b) detect errors reported by SetPropert(y|ies)Rule (or cause them to be fatal. Though it might be better to report several errors at once). Maybe an error counter in Digester. c) check not only server.xml but other configuration files as well 3) Maybe there are ways to address points 5. and 6. above. Regarding Migration docs: 2011/12/2 Christopher Schultz <ch...@christopherschultz.net>: > >> How about mentioning your issue somewhere in the FAQ? Though I think >> it is already mentioned on >> http://apache.org/migration.html > > http://tomcat.apache.org/migration.html does not contain the string > "server.xml", though I haven't through the actual text -- just searched > for server.xml. I'd be happy to take a look at the guide and make some > additions. > Because there are several files, not just server.xml. See "Before upgrading or migrating" chapter at the very top. Improvements are always welcome. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
