On 16/06/2012 16:28, Konstantin Kolinko wrote: > 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.
There will need to be a hard dependency to handle some of the welcome file rules. > 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 be fine with that (or pretty much any other name - I'm not tied to any naming conventions). >> 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. Things will hopefully become a little clearer as I start to commit stuff but there will be separate implementations for File, Dir and Jar with possibly another three implementations for URL based access rather than Direct access (I want to wait until I see how similar the implementations are before I decide exactly how to handle that). WAR is essentially a special case (since it is the wrapper for all resources) that will use either Dir or Jar for it's 'main' resources. > 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). It is the plumbing I want to bypass. I think direct file (and probably URL) access will be simpler to maintain and hopefully faster. > org.apache.naming.* will survive, because Tomcat still needs JNDI support . Agreed. > URLs are needed per Servlet API, so they cannot be removed. Does our > "jndi" schema need DirContext as underlying implementation? Our jndi scheme was used to provide access to resources. I believe all of that will now go. > 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:". No we won't. We only hadf to deal with URLs like that because we generated them. > 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 don't recall that but this will fix that minor issue too. > 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 think it just gets removed. >> 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. I plan just to commit the new interfaces to start with and they will include lots of Javadoc. > Best regards, > Konstantin Kolinko Thanks for the feedback --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
