tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/ webapps/docs/changelog.xml
Date Sat, 15 Sep 2007 16:31:59 GMT
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
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
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
the other. Wouldn't plain old links ( with an argument to relax the path
checks ) be
enough ? Or a user-space solution ?


On 9/14/07, Filip Hanik - Dev Lists <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message