tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Proposal: use tomcat-version-number in server.xml <Server> element?
Date Fri, 02 Dec 2011 17:26:41 GMT
On 12/2/2011 10:11 AM, Konstantin Kolinko wrote:
> 2011/12/2 Christopher Schultz<chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message