tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.
Date Sat, 15 Sep 2007 17:27:30 GMT
On 9/15/07, Jim Jagielski <jim@jagunet.com> wrote:
>
> Costin Manolache wrote:
> >
> > 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.
> >
>
> Just to be clear; Is the veto against the actual patch or the feature?
> If for the actual patch, then maybe you and Remy could provide feedback
> to Tim on what would make it acceptable... If for the actual feature,
> then I'm not sure how to jive that with your 2nd statement about a simple
> vote...


My understanding was that veto can only be against a patch.

And for a feature - some majority would do it.

Regarding feedback on patch - I think I expressed my concerns:
- more analysis and understanding of security implications
- if possible to do it at a different (higher) level
- if it can be done in a modular fashion, i.e. keeping the default impl the
way it is,
without this feature, and adding a way to configure a different module with
this or
other features. ( bonus points if the add-on module is a separate release
and very easy
to add )

In other words - bloat ( same as Remy's concern I guess) and understanding
if this is the
best possible implementation if the bloat is deemed acceptable.

Costin

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