2012/6/15 Mark Thomas <ma...@apache.org>: > All, > > Servlet 3.1 looks like it is going to introduce 'overlays' or something > similar along the lines of the enhancement request [1]. > > Tomcat already has aliases, VirtualDirContext and resource JAR support - > each implemented slightly differently. Things are already rather messy > and will get worse if we build on what we currently have. I have > therefore been looking at a new Resources implementation for Tomcat 8 > that is not based on DirContext. > > Along the way I have noticed a few related refactorings that will be > required / would make life easier. They are: > > 1. Move Loader and Resources from Container to Context > The docs already state these are only for Contexts and they don't > make much sense on other Containers.
OK. > 2. Move Mapper to o.a.catlina.connector.mapper > It is only used here and removing DirContext means it will have a > hard dependency on o.a.c.resources (or wherever the new implemenation > goes) so can't stay in o.a.tomcat.util Most of Mapper is agnostic on whatever technology if behind it. MappingData class stores Objects instead of Host, Context etc. Having a DirContext there already means that this abstraction is leaking, so I do not mind the move. I wonder whether interfaces and implementation will be separate, so that Mapper were not really "hard" dependent on implementation details. BTW, maybe "o.a.c.resource". We have "resources" packages elsewhere (Jasper, javax.servlet.**) and they contain some supplementary data, not code. The o.a.naming.resources package is an exception. > I'd like to complete these before I start the main refactoring to a) do > things in stages b) do the bigger refactoring from a slightly cleaner start. > > The broader refactoring aims to provide aliases, overlays, resource JARs > and anything else along those lines through a common interface with the > implementations going directly to the file system. Access via URLs will > also be supported but direct access to the file system will be > preferred. How are you going to handle unpacked WARs ? Some abstraction will still be needed. I wonder how much will it differ from DirContext. DirContext served it purpose, but it looks that it requires too much plumbing (dealing with Names etc). I wonder whether it can survive as a facade to new API. (Though I do not yet know a valid purpose to keep such facade). org.apache.naming.* will survive, because Tomcat still needs JNDI support . URLs are needed per Servlet API, so they cannot be removed. Does our "jndi" schema need DirContext as underlying implementation? I noticed the following commit in archives: http://svn.apache.org/viewvc?view=revision&revision=1137646 so we have to deal with such schema combinations as "jar:jndi:". IIRC there was once a person who complained that our "jndi" schema was clashing with some other implementation of "jndi" schema in an application where he was trying to embed Tomcat. I cannot find that thread in the archives though. I wonder what will happen with org.apache.naming.JndiPermission http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html#Tomcat_Custom_Permissions > I have some rough ideas for this. My plan is to commit the > new classes as I go along so folks can comment and provide feedback but > only commit the changes to existing classes once I have everything working. OK. Though if it is work in progress maybe some comments/summaries will be needed to understand how it is going to be integrated with existing code. > Since this is fairly major work, any objections before I start? > > Cheers, > > Mark > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52236 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
