Well, regarding the veto - it's simple. I second Remy's opinion that the veto is valid and the change is not right at the moment, and I guess that should close this discussion.
The discussion about whether to add such a feature or not - I think a simple vote would solve this as well, it's quite a subjective and taste-based issue. There are many other features that serve a small number of users only, the usual question was if enough tomcat developers are willing to support and want the feature. On how to implement such a feature ( if a consensus or majority exists to add it ) - I would like to know what are the alternatives and exact requirements, I don't think JNDI impl level is best ( well, it has LinkRef and LDAP supports this kind of aliases ). If it's just about serving files - maybe refactoring default servlet to make it extensible and having a user-space servlet would be enough ( that may also be more portable )? On security issues, yes, Apache has this feature but I vaguely remember it had a couple of security issues related to it. So it is not a trivial 'it is secure', but 'it requires a lot of checking to make sure it is' On deployment - yes, I agree there are different views, I'm on 'self-contained and easy to replicate is better than single-machine flexibility' side but I can understand the other. Wouldn't plain old links ( with an argument to relax the path checks ) be enough ? Or a user-space solution ? Costin On 9/14/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > 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 > > Filip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
