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
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
Filip
(Someone cited an article from year 2001 just recently. Surprisingly
it was still relevant - that part of Servet spec did not change much).
4. Version number can be changed by vendor or by site Admin.
Speaking of "relying on features":
- Tomcat 6 server.xml should not start with Tomcat 7, because some
LifeCycle listener implementations were removed.
- Tomcat 5.5 and 6.0 differ in loader configuration in catalina.properties
How about mentioning your issue somewhere in the FAQ? Though I think
it is already mentioned on
http://apache.org/migration.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
