Re: [Proposal] Preparatory refactoring for Resource handling refactoring
On 17/08/2012 16:50, Konstantin Kolinko wrote: > (regarding DefaultServlet) >>> If it were using the servlet API only, the code were more reusable, >>> both inside and outside of Tomcat. There must be specific issue why >>> Servlet API is not used there. Is the API lacking? >> >> In lot of ways. For example, where is the API to create or delete >> resources? That is deliberately left as a container implementation detail. >> > > OK. One way is to use getRealPath() + manipulate files on the file > system directly. I agree that using the API (be it DirContext or > something else) is a bit more nice. getRealPath() won't work for read/write storage that isn't backed by a file system (e.g. database backed) It also gets rather expensive when you have to deal with static resources from multiple sources. You end up needing a several calls to work out a) if the resource exists, b) if it can be put / deleted depending on whether the resource is from a resource JAR, collides with one from a resource JAR etc. Not impossible, but you need quite a few calls to get it right. This gets more complicated when you add overlays to the mix. >> The jndi layer has caused performance problems as well. The special >> handling for JARs is a direct result of that. The new approach will >> simplify a lot of that and hopefully improve performance as well. Like >> we have with the current approach, if there are specific areas causing >> problems, we can take a look. I hope and expect that far fewer of these >> 'tweaks' would be required with the new implementation. >> > One good thing with "jndi:" URLs returned via Servlet API is that they > are backed by an instance of ProxyDirContext class and it has a cache > (*). If we change implementation and return "true" URLs, they will > bypass the cache. I suspect that using a "jar:" URL directly (in case > of an unpacked WAR file) may have poor performance. The new Resources implementation will include caching where necessary. At the moment there is none. I intend to add it as required. I agree JARs/WARs are likely to need it to have performance that is comparable with expanded WARs. > > Regarding this caching: > 1. Currently calling getInputStream() on a jndi URL may return > resource directly from memory (cached by ProxyDirContext). > > If a file URL is used that would involve direct reading from hard > drive. If a jar URL is used - I wonder whether opening of the JAR > file by the system had to be performed regardless of independent > access to the same file. > > One may argue though that there is > ServletContext.getResourceAsStream() method available. > > 2. If I query some attributes of the resource via > getResource().openConnection().getHeaderField(), for jndi URLs they > are returned from a cache. I wonder what performance will be there > with file and jar URLs. I remain to be convinced how much caching is required. My preference is to add a very simple (possibly even NO-OP) caching layer that we can extend as necessary to address actual performance issues rather than guessing where they might occur. >> I can put a patch of the changes so far on people.a.o if you are >> interested (note: it won't compile yet). >> > > I would like to look and review. I think that at the current point > this refactoring should not be done directly on trunk without some > review and consensus first. I've almost got something working. I'll see if I can finish it off first. Either way I'll aim to post something this coming weekend. > Maybe create a branch for this work (create a "tomcat/branches/" > directory, or use existing "tomcat/sandbox")? I'm happy with that if required. I suggest we hold of on the how until folks have had a chance to look at the patch first. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
(regarding DefaultServlet) >> If it were using the servlet API only, the code were more reusable, >> both inside and outside of Tomcat. There must be specific issue why >> Servlet API is not used there. Is the API lacking? > > In lot of ways. For example, where is the API to create or delete > resources? That is deliberately left as a container implementation detail. > OK. One way is to use getRealPath() + manipulate files on the file system directly. I agree that using the API (be it DirContext or something else) is a bit more nice. > > The jndi layer has caused performance problems as well. The special > handling for JARs is a direct result of that. The new approach will > simplify a lot of that and hopefully improve performance as well. Like > we have with the current approach, if there are specific areas causing > problems, we can take a look. I hope and expect that far fewer of these > 'tweaks' would be required with the new implementation. > One good thing with "jndi:" URLs returned via Servlet API is that they are backed by an instance of ProxyDirContext class and it has a cache (*). If we change implementation and return "true" URLs, they will bypass the cache. I suspect that using a "jar:" URL directly (in case of an unpacked WAR file) may have poor performance. >>> >>> The new Resources implementation will include caching where necessary. >>> At the moment there is none. I intend to add it as required. I agree >>> JARs/WARs are likely to need it to have performance that is comparable >>> with expanded WARs. >>> Regarding this caching: 1. Currently calling getInputStream() on a jndi URL may return resource directly from memory (cached by ProxyDirContext). If a file URL is used that would involve direct reading from hard drive. If a jar URL is used - I wonder whether opening of the JAR file by the system had to be performed regardless of independent access to the same file. One may argue though that there is ServletContext.getResourceAsStream() method available. 2. If I query some attributes of the resource via getResource().openConnection().getHeaderField(), for jndi URLs they are returned from a cache. I wonder what performance will be there with file and jar URLs. > > I can put a patch of the changes so far on people.a.o if you are > interested (note: it won't compile yet). > I would like to look and review. I think that at the current point this refactoring should not be done directly on trunk without some review and consensus first. Maybe create a branch for this work (create a "tomcat/branches/" directory, or use existing "tomcat/sandbox")? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
On 30/07/2012 15:48, Konstantin Kolinko wrote: > 2012/7/30 Mark Thomas : >> On 30/07/2012 01:16, Konstantin Kolinko wrote: >>> If we remove JNDI stuff from resource handling, one of "challenges" >>> might be to re-implement DefaultServlet using only Servlet API >>> methods. Well, if the former is not possible, it might use the new >>> resources API (that you are going to implement instead of jndi one) >>> and be thus still tied with Tomcat internals... >> >> This is a non-issue in my view. The current DefaultServlet uses Tomcat >> internals extensively. The new implementation will to. >> > > I am just saying that it is feels unfair. It is no better or worse than the current approach in that respect. > If it were using the servlet API only, the code were more reusable, > both inside and outside of Tomcat. There must be specific issue why > Servlet API is not used there. Is the API lacking? In lot of ways. For example, where is the API to create or delete resources? That is deliberately left as a container implementation detail. > Well, bypassing > the API we can get hands on simpler objects and waste less time > processing them. There is some of that, but a lot of it is functionality that we have to implement. > If it is not a replacement for the current implementation, it might be > a new sample servlet for the examples webapp. > >>> If one reimplements DefaultServlet, one of the tasks would be to >>> generate directory listings. Those include file size and file >>> timestamp. One needs to obtain URL of a resource, open its >>> URLConnection and ask those attributes. >> >> Only if doing so entirely via the Servlet API which we don't need to do. >> > > Others will use Servlet API, and dropping performance is a bad option. The jndi layer has caused performance problems as well. The special handling for JARs is a direct result of that. The new approach will simplify a lot of that and hopefully improve performance as well. Like we have with the current approach, if there are specific areas causing problems, we can take a look. I hope and expect that far fewer of these 'tweaks' would be required with the new implementation. >>> One good thing with "jndi:" URLs returned via Servlet API is that they >>> are backed by an instance of ProxyDirContext class and it has a cache >>> (*). If we change implementation and return "true" URLs, they will >>> bypass the cache. I suspect that using a "jar:" URL directly (in case >>> of an unpacked WAR file) may have poor performance. >> >> The new Resources implementation will include caching where necessary. >> At the moment there is none. I intend to add it as required. I agree >> JARs/WARs are likely to need it to have performance that is comparable >> with expanded WARs. >> >>> Other good thing is that you can create relative URLs as "new URL(Url, >>> String)", which inherits URLStreamHandler instance from the original >>> URL, and thus inherits access to ProxyDirContext instance. If it is a >>> "jndi" URL it will have access to the full resources hierarchy of the >>> web application. If it is a "true" URL, it will be limited to its >>> origin file system. >> >> That is true, but why is that necessary? Is it a specification >> requirement? I'm not aware of it. The canonical identifier is the path >> of the resource within the app, not the URL returned from getResource() >> > > It is an existing feature. Removing a feature is bad and needs a good reason. The good reason is cleaning up the code, making the 'overlay' feature in Servlet 3.1 possible. You only have to look at the catalogue of problems the VirtualClassLoader and VirtualDirContext have introduced to imagine how difficult it would be to implement 'overlays' with the current code base. The refactoring makes things a lot, lot cleaner. > BTW, it you wanna take a look at a use case of it, I noticed one place > yesterday. That code is a direct result of a jndi URL being returned. No jndi URLs, no need for that code. The ContextConfig is one of the few parts of the code base I still need to refactor. The other part that is left is the Mapper. The rest is complete but untested. I'd like to have something that at least passes the TCK before committing it. I can put a patch of the changes so far on people.a.o if you are interested (note: it won't compile yet). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
2012/7/30 Mark Thomas : > On 30/07/2012 01:16, Konstantin Kolinko wrote: >> If we remove JNDI stuff from resource handling, one of "challenges" >> might be to re-implement DefaultServlet using only Servlet API >> methods. Well, if the former is not possible, it might use the new >> resources API (that you are going to implement instead of jndi one) >> and be thus still tied with Tomcat internals... > > This is a non-issue in my view. The current DefaultServlet uses Tomcat > internals extensively. The new implementation will to. > I am just saying that it is feels unfair. If it were using the servlet API only, the code were more reusable, both inside and outside of Tomcat. There must be specific issue why Servlet API is not used there. Is the API lacking? Well, bypassing the API we can get hands on simpler objects and waste less time processing them. If it is not a replacement for the current implementation, it might be a new sample servlet for the examples webapp. >> If one reimplements DefaultServlet, one of the tasks would be to >> generate directory listings. Those include file size and file >> timestamp. One needs to obtain URL of a resource, open its >> URLConnection and ask those attributes. > > Only if doing so entirely via the Servlet API which we don't need to do. > Others will use Servlet API, and dropping performance is a bad option. >> One good thing with "jndi:" URLs returned via Servlet API is that they >> are backed by an instance of ProxyDirContext class and it has a cache >> (*). If we change implementation and return "true" URLs, they will >> bypass the cache. I suspect that using a "jar:" URL directly (in case >> of an unpacked WAR file) may have poor performance. > > The new Resources implementation will include caching where necessary. > At the moment there is none. I intend to add it as required. I agree > JARs/WARs are likely to need it to have performance that is comparable > with expanded WARs. > >> Other good thing is that you can create relative URLs as "new URL(Url, >> String)", which inherits URLStreamHandler instance from the original >> URL, and thus inherits access to ProxyDirContext instance. If it is a >> "jndi" URL it will have access to the full resources hierarchy of the >> web application. If it is a "true" URL, it will be limited to its >> origin file system. > > That is true, but why is that necessary? Is it a specification > requirement? I'm not aware of it. The canonical identifier is the path > of the resource within the app, not the URL returned from getResource() > It is an existing feature. Removing a feature is bad and needs a good reason. BTW, it you wanna take a look at a use case of it, I noticed one place yesterday. In ContextConfig.processAnnotationsJndi(...) there is code [[[ Enumeration dirs = dcUrlConn.list(); while (dirs.hasMoreElements()) { String dir = dirs.nextElement(); URL dirUrl = new URL(url.toString() + '/' + dir); processAnnotationsJndi(dirUrl, fragment, handlesTypesOnly); } ]]] It creates a relative URL there. If it were using the constructor for relative URLs, new URL(url, dir), it would have better performance, because URLStreamHandler were inherited from the old URL. A question that needs testing before making a change there, though, is whether the old URL ends with "/" (and thus is a directory). The code behaves as if it did not have the trailing "/". >> The above two are the reasons why I think that in Tomcat 8 we cannot >> return "true" URLs from ServletContext.getResource(String) method and >> must still support the "jndi:" or some other proprietary URL schema. > > I agree that the second issue would require a custom URL scheme if it > were a requirement but I am not aware of anything that states that it is. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
On 30/07/2012 01:16, Konstantin Kolinko wrote: > If we remove JNDI stuff from resource handling, one of "challenges" > might be to re-implement DefaultServlet using only Servlet API > methods. Well, if the former is not possible, it might use the new > resources API (that you are going to implement instead of jndi one) > and be thus still tied with Tomcat internals... This is a non-issue in my view. The current DefaultServlet uses Tomcat internals extensively. The new implementation will to. > If one reimplements DefaultServlet, one of the tasks would be to > generate directory listings. Those include file size and file > timestamp. One needs to obtain URL of a resource, open its > URLConnection and ask those attributes. Only if doing so entirely via the Servlet API which we don't need to do. > One good thing with "jndi:" URLs returned via Servlet API is that they > are backed by an instance of ProxyDirContext class and it has a cache > (*). If we change implementation and return "true" URLs, they will > bypass the cache. I suspect that using a "jar:" URL directly (in case > of an unpacked WAR file) may have poor performance. The new Resources implementation will include caching where necessary. At the moment there is none. I intend to add it as required. I agree JARs/WARs are likely to need it to have performance that is comparable with expanded WARs. > Other good thing is that you can create relative URLs as "new URL(Url, > String)", which inherits URLStreamHandler instance from the original > URL, and thus inherits access to ProxyDirContext instance. If it is a > "jndi" URL it will have access to the full resources hierarchy of the > web application. If it is a "true" URL, it will be limited to its > origin file system. That is true, but why is that necessary? Is it a specification requirement? I'm not aware of it. The canonical identifier is the path of the resource within the app, not the URL returned from getResource() > The above two are the reasons why I think that in Tomcat 8 we cannot > return "true" URLs from ServletContext.getResource(String) method and > must still support the "jndi:" or some other proprietary URL schema. I agree that the second issue would require a custom URL scheme if it were a requirement but I am not aware of anything that states that it is. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
2012/6/17 Mark Thomas : > On 16/06/2012 19:18, Mark Thomas wrote: >> >> >> Konstantin Kolinko wrote: >> >>> 2012/6/16 Mark Thomas : > 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. >>> >>> How are you going to implement ServletContext.getResource(String): >>> URL >>> >>> without a custom URL scheme (be it named "jndi" or somehow else)? >>> >>> For file resources it might be possible to produce the "actual" >>> URL pointing to a JAR entry or to a file (leaving aside the >>> question of whether it exposes too much details), but you cannot >>> do so with directories, as entries in a directory can be assembled >>> from several sources. >> >> My intention was to use the URL for the actual resource. For >> directories, I'll use the first matching dir I find although I need >> to re-read the spec and Javadoc to make sure there aren't any nasty >> surprises waiting to trip me up. > > Having re-read the specification and Javadoc, I don't see anything of > concern. Additional pairs of eyes wouldn't hurt though. > > How to handle getResource() for a directory that exists in one or more > overlays and/or the main WAR is an interesting question. I'll be sure to > raise it within the Servlet EG when we get back to that question. > If we remove JNDI stuff from resource handling, one of "challenges" might be to re-implement DefaultServlet using only Servlet API methods. Well, if the former is not possible, it might use the new resources API (that you are going to implement instead of jndi one) and be thus still tied with Tomcat internals... If one reimplements DefaultServlet, one of the tasks would be to generate directory listings. Those include file size and file timestamp. One needs to obtain URL of a resource, open its URLConnection and ask those attributes. One good thing with "jndi:" URLs returned via Servlet API is that they are backed by an instance of ProxyDirContext class and it has a cache (*). If we change implementation and return "true" URLs, they will bypass the cache. I suspect that using a "jar:" URL directly (in case of an unpacked WAR file) may have poor performance. Other good thing is that you can create relative URLs as "new URL(Url, String)", which inherits URLStreamHandler instance from the original URL, and thus inherits access to ProxyDirContext instance. If it is a "jndi" URL it will have access to the full resources hierarchy of the web application. If it is a "true" URL, it will be limited to its origin file system. The above two are the reasons why I think that in Tomcat 8 we cannot return "true" URLs from ServletContext.getResource(String) method and must still support the "jndi:" or some other proprietary URL schema. (*) for reference: TTL of entries in ProxyDirContext#cache is by default 5 seconds (5000). If the time has elapsed, the resource is revalidated by comparing its timestamp with original one The TTL is configured via ProxyDirContext constructor <- BaseDirContext#cacheTTL <- StandardContext#cacheTTL and thus is configurable on a . http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Mark, On 6/15/12 1:00 PM, Mark Thomas wrote: > Since this is fairly major work, any objections before I start? I like the unification of all these things. Would this be a good time to consider making Tomcat 7 RTC with such a significant change to the core of the trunk? -chris signature.asc Description: OpenPGP digital signature
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
On 16/06/2012 19:18, Mark Thomas wrote: > > > Konstantin Kolinko wrote: > >> 2012/6/16 Mark Thomas : >>> 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. >>> >> >> How are you going to implement ServletContext.getResource(String): >> URL >> >> without a custom URL scheme (be it named "jndi" or somehow else)? >> >> For file resources it might be possible to produce the "actual" >> URL pointing to a JAR entry or to a file (leaving aside the >> question of whether it exposes too much details), but you cannot >> do so with directories, as entries in a directory can be assembled >> from several sources. > > My intention was to use the URL for the actual resource. For > directories, I'll use the first matching dir I find although I need > to re-read the spec and Javadoc to make sure there aren't any nasty > surprises waiting to trip me up. Having re-read the specification and Javadoc, I don't see anything of concern. Additional pairs of eyes wouldn't hurt though. How to handle getResource() for a directory that exists in one or more overlays and/or the main WAR is an interesting question. I'll be sure to raise it within the Servlet EG when we get back to that question. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Konstantin Kolinko wrote: >2012/6/16 Mark Thomas : >> >>> 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. >> > >How are you going to implement >ServletContext.getResource(String): URL > >without a custom URL scheme (be it named "jndi" or somehow else)? > >For file resources it might be possible to produce the "actual" URL >pointing to a JAR entry or to a file (leaving aside the question of >whether it exposes too much details), but you cannot do so with >directories, as entries in a directory can be assembled from several >sources. My intention was to use the URL for the actual resource. For directories, I'll use the first matching dir I find although I need to re-read the spec and Javadoc to make sure there aren't any nasty surprises waiting to trip me up. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
2012/6/16 Mark Thomas : > >> 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. > How are you going to implement ServletContext.getResource(String): URL without a custom URL scheme (be it named "jndi" or somehow else)? For file resources it might be possible to produce the "actual" URL pointing to a JAR entry or to a file (leaving aside the question of whether it exposes too much details), but you cannot do so with directories, as entries in a directory can be assembled from several sources. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
On 16/06/2012 16:28, Konstantin Kolinko wrote: > 2012/6/15 Mark Thomas : >> 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
Re: [Proposal] Preparatory refactoring for Resource handling refactoring
2012/6/15 Mark Thomas : > 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
[Proposal] Preparatory refactoring for Resource handling refactoring
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. 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 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. 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. Since this is fairly major work, any objections before I start? Cheers, Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52236 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org