If it helps, here is a draft: https://github.com/apache/tomcat/pull/630
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 26 juin 2023 à 10:53, Mark Thomas <ma...@apache.org> a écrit : > On 25/06/2023 13:50, Romain Manni-Bucau wrote: > > Hi all, > > > > Doing some tests I realized two things: > > > > * tomcat still uses File a lot (thinking to default servlet stack) > > * tomcat does not uses FileSystem abstraction and previous point would > only > > makes sense with this addition > > > > What about a (nio) Fileystem/Path based implementation of WebResourceSet? > > It would enable to not only rely on local filesystem but also more exotic > > ones (in mem for ex). > > Was it already discussed/studied? > > I don't recall any discussions. There have been a few discussions around > using custom implementations of various WebResouce classes but that has > generally been to customize some specific behaviour. > > > Would it makes sense in tomcat codebase? > > It depends if there is demand for it. My initial reaction is "probably > not". > > Where I think there probably is room for improvement is some refactoring > to make it easier to use custom implementations for different parts of > the WebResource implementation. Picking a random example, custom JAR > handling to validate signatures. > > If there is a demand for extending WebResource, making it easier to have > custom implementations will hopefully give us an insight into what that > demand is. If there was something folks were consistently asking for > then it would make sense to include it in the default Tomcat distribution. > > All that said, I do think if there was a demand for this sort of > functionality we would have seen some indication of that on the users > list. But maybe it is chicken/egg situation so I am in favour of making > custom extensions/implementations easier and seeing what happens. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
