tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/ webapps/docs/changelog.xml
Date Thu, 13 Sep 2007 17:42:41 GMT

I was tempted to post a patch first and discuss, but since it was only a 
setZZZ addition and the functionality is exactly the same when the 
parameter is NOT set - I thought this could go CTR. In light of the 
recent CTR/RTC discussions - we are still CTR until the vote passes. 
Likewise - while this is an API change - I guess my expectation on API 
change was anything that breaks backwards compatibility. (method 
signature changes) Unless someone subclassed FileDirContext and used the 
method names in the patch - then no one (user community) would notice.

When I first wrote this, my first pass was to subclass it where I could 
just call files() but that didn't work due since I still had to change 
other methods. I'd have to do a more comprehensive change (more risky 
IMO) to FileDirContext before I'd be able subclass it effectively.

The real use case is where you have uploaded files, or just a bunch of 
other files sitting in a different location on disk. You need to make 
them look as part of the current webapp while not having to rely on 
symlinks. So the feature is "similar" to the Alias directive in apache.

Since you -1 - I'd like to have a technical reason on why to back the 
patch out. Then I'd be glad to do so or make the appropriate changes. If 
the reason is - I think its bloat - I'm not sure how to resolve this issue.

[I'm actually on vacation this week so my replies might be slower than 


Remy Maucherat wrote:
> wrote:
>> Author: funkman
>> Date: Thu Sep 13 08:19:59 2007
>> New Revision: 575332
>> URL:
> The reasonable thing would have been to talk a bit about it. I think 
> using a subclass (assuming you really want to put this in, which I don't 
> really like - small euphemism) would be more reasonable.
> Since you did not do any of this, I will have to veto this patch.

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

View raw message