tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml
Date Fri, 14 Sep 2007 20:14:13 GMT

On Sep 14, 2007, at 3:50 PM, Remy Maucherat wrote:

> Jim Jagielski wrote:
>> On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
>>>
>>> It may also have some implications on other use cases -  
>>> deployment ( the
>>> current pattern
>>> is that all files for a webapp are in one place ), replication  
>>> ( i.e. if
>>> someone wants same webapps
>>> on a pool of servers ).
>>>
>> To me this is an important point... the beauty of
>> webapps is that, well, they are self contained.
>> But I can also easily see the advantage, from an admin
>> and even developer PoV for more flexibility.
>> Basically, of course, Aliases are runtime configurations
>> of what could be done via file-system provided symlinks...
>> So the security and API issues should see what, if anything,
>> can be gleamed from that...
>
> 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 agree that if you use this feature, then portability is
broken. But does *providing* this, in and of itself,
break portability? Basically this would be a "feature"
that if not used, from what it appears to me, adds no
overhead or concerns. However, for those who do choose to
use it, they break portability... So, assuming that
TC does All The Right Things internally when passed
an Alias, the question boils down to TC saying "We
don't think you should do this and we aren't going
to make it easy for you to do so" or "We don't
think you should be doing this, but since you are
anyway, here's an 'official' way of doing it".




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message