On 23.09.2013 17:27, Mark Thomas wrote: > I've mentioned on a couple of different threads that refactoring how the > class loader accesses resources was on my TODO list. I haven't done any > implementation yet but I have some ideas that I wanted to get some > feedback on before I start work. > > The things I have in mind at this point are: > - Extracting anything into the work directory feels like a hack > - The class loader should use the same API as every other component > - The class loader needs URLs that actually work > - The anti-locking options are responsible for a number of the hacks in > the class loader > > The solution I have in mind is along the following lines: > - Add a new getClassLoaderResource() to the WebResources interfaces. > This will implement the standard WEB-INF/classes then JARs in > WEB-INF/lib search order. It should be able to do this without any > extraction into the work directory.
A useful feature in TC 6/7 was to add search paths outside of the war to look for config files in order to provide config options special to deployment environments without working with individual war files (via VirtualWebappLoader). I know it is possible with the current resource implementation in TC 8, but will it also be possible after this change, i.e. if the webapp retrieves a config file as a resource via the webapp class loader, can we still configure additional directories to be searched for the resource? > - Class loader resources will not be cached. > - Remove all of the current anti-locking options. > - Wrap all InputStreams returned by the class loader and use this > wrapper to track whether or not the InputStream has been closed. > - Update the memory leak protection code to close any class loader > InputStreams that have not been closed when the web application is > stopped. > - Add a debug option that captures the stack trace of the code that > creates the class loader InputStream that can be reported when > closing leaked streams. > - Add the same InputStream tracking to InputStreams provided by the > standard resource implementation. > > Obviously details TBD as the implementation evolves. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
