tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
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 20:13:03 GMT
Tim Funk wrote:
> D'oh.
> 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.

The reasons are:
This sort of features reduces portability (= must be included with 
caution), can cause a lot of hacking (generally not good), and is going 
to have to get supported (= the capabilities and configuration need some 
review). None of these are very serious, but it adds up.

It's not a real veto anyway, but no proper review mechanism exists at 
the moment, and it's hard to integrate feature additions in 6.0.x 
without prior discussion.


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

View raw message