tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/ webapps/docs/changelog.xml
Date Fri, 14 Sep 2007 20:42:04 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Yes, this is hard to compare to httpd, as in the case of Tomcat, 
>>> there is precise specification which defines a portable web 
>>> application packaging. I see the latest changes have all aimed at 
>>> breaking portability, and I don't like that at all.
>> I don't subscribe to this point of view, basically, if that was the 
>> case, we wouldn't have META-INF/context.xml as a feature either (as 
>> just one example).
>> Portability is not something that is enforced by Tomcat, but by the 
>> spec. So if a user writes a portable webapp on weblogic, then the 
>> spec (and tomcat) make that webapp being able to run on Tomcat. and 
>> the other way around. However, pretty much every single servlet 
>> engine, Tomcat included, does add additional features, useful to the 
>> users for the frameworks.
>> If Tomcat didn't have any custom features, then it wouldn't be half 
>> as popular as it is today.
> This is history rewriting. Actually, people used it (in that order) 
> because of:
> - it was a component of the RI, which meant not too many spec breaking 
> features, and that an app that ran on Tomcat was likely to run on the 
> production server (which was rarely Tomcat)
> - the Apache brand
> - relatively small and light
>> Writing a portable webapp, is doable, and essentially has nothing to 
>> do with the optional feature set in Tomcat. If you want a portable 
>> webapp, simply don't use the non portable features in Tomcat.
> It's another strategy: add as many of the features that a few users 
> ask for, regardless of what the specification. This is what many 
> commercial appservers often do, basically. It's quite amazing you 
> cannot seem to accept that I do not like this policy.
I totally accept that you dont like the policy, but it doesn't justify 
vetos. and that has been one of the core of the issues.
the one time it would fly for a veto would be when, a) others feel the 
same, b) no one likes the feature


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

View raw message