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. - 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. Thoughts? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
